Practical applications of systems
engineering do not have to bear the hallmarks of the latest
systems tools and techniques or be conducted using the in-vogue
terms of the discipline. Indeed, as many of us in the profession
already recognise, systems engineering is often done
"naturally", even unconsciously, as it were, its
beneficial effects passing into a successful end-product
unrecognised as an application of sound systems engineering
principles. Even some of the discipline's strongest proponents
have only recognised after the event that what they found
themselves doing at some point in their careers was actually
systems engineering!
This paper describes how a systems
engineering function evolved naturally during the engineering of
the Channel Tunnel one of the largest single infrastructure
projects ever tackled and certainly the largest ever to have been
entirely privately financed. Designed and built by TML
(Transmanche Link), a consortium of ten British and French
construction companies, the project emphasis was always on
earliest possible completion using tried and tested technology
and well established construction industry methods. However, an
entirely new transport system was, nevertheless, being created
requiring very effective systems engineering techniques to be
developed "hot-foot", as it were, during the course of
the design development process. Not only were these techniques
successfully developed and applied, they were also specifically
adapted to the construction industry environment with its strong
emphasis on physical realisation within target date and cost
constraints.
This paper addresses the integration of the
human component into system design. It describes the background
to the changes that are taking place throughout the world's
defence industry. Whilst the driving forces for this change has
been military the underlying problem applies to all systems of
any real complexity. The paper considers the problems of
designing complete systems that include not only hardware,
software, but also the people who must operate and support them
during their service life. It outlines a programme that British
Aerospace Defence is implementing to integrate the human factors
into the design process. It highlights the principal problems
encountered when trying to design for the end user, and finally
identifies the support required from the MoD and other customers
in designing effective systems.
Many systems fail to deliver their potential
benefits. Major problems are found when the system has been
procured and is going into service or during trials of the
system. This is especially true of systems that in themselves may
be complex and have major interoperability requirements with
other systems. Even relatively minor problems discovered at that
stage can result in large cost and timescale over-runs, and can
cause loss of planned functionality and perceived benefit.
Increasingly, standard system components can be specified to
provide detailed functionality and it is the integration of
systems and their interoperation with other systems that are the
cause of problems.
To tackle these problems, validation of
design is required early in the procurement life cycle to address
the system behaviour and study the way in which components
interact. Finite state machines describe systems in terms of
existing in a number of different states with transitions between
those states. However, they are conceptually difficult to relate
to other views of the system.
Behaviour Diagrams provide an executable
model of the functionality of a system or interoperating systems,
as an extended finite state machine. They provide the means to
model sequential and parallel processing, include representation
of functions, control, states, information passing and storage.
Unlike many techniques, Behaviour Diagrams allow the
representation of a system with multiple allowed states which
exist concurrently and are intimately related to the functions
and messaging within the system. Large systems can be modelled
using the behaviour diagram method to create a hierarchy, complex
functions are themselves modelled as behaviour diagrams.
This work demonstrates the development of
Behaviour Diagrams for a complex system from conventional finite
state machine and recognises the advantages that can be gained
from this technique. In addition, support for the Behaviour
Diagramming technique provided by a commercial systems
engineering support tool, allows for simulation that provides
validation of logic and operation. The use of such a computer
based tool to support a systems engineering repository provides a
major advantage over other methods. Further work into the use of
Behaviour Diagrams for the support of systems engineering
activities is in progress.
This paper examines the nature of systems
engineering from a fundamental viewpoint. It discovers that the
foundations for this approach are set in a belief in the absolute
nature of the world and our ability to understand it. This belief
has been challenged in the field of science, most notably by the
philosopher and scientist Karl Popper. But this challenge has not
been reflected in engineering. However, the concept of 'soft'
systems can be seen to embrace this new science, and this paper
tries to show how this concept can be underpinned and extended to
provide a foundation capable of supporting the entire systems
engineering discipline.
The use of Yourdon-based functional
modelling techniques for the requirements analysis and system
design of naval combat systems was pioneered by VSEL in the late
1980s on the MOD sponsored SSN20 submarine project. Since then
these techniques have been progressively developed and employed
at both the combat system and equipment levels on an increasing
variety of studies.
This paper will survey the use of these
techniques on combat system studies including Swiftsure and
Trafalgar class tactical weapon system update. Vanguard SSBN, the
future frigate and landing platform dock (replacement) and
describes the technique developments currently taking place, such
as in the development and use of generic models.
It will describe how the techniques can be
used for purposes such as configuration management and equipment
specification. assessment and selection and indicate how the
techniques can be applied throughout the system life cycle and as
part of a systematic, integrated approach to combat system
development and procurement.
The RA (Requirement Analysis) process
undertaken at any point during the SEP (Systems Engineering
Process) results in some representation of the problem to be
solved by the remaining activities. The outputs of this process
are paramount to the success of the subsequent activities
resulting in the creation of an effective system.
The 'competition baseline' establishes the
requirements against which competing enterprises will be
evaluated during a competitive tender. Implementing the RA
process correctly in the production of this baseline affords
benefits to both the customer and the competing enterprises.
A process for the creation of the competition
baseline requirements set has been developed and implemented for
the RMPA project. The process provides an example of how the IEEE
P1220 approach to RA can be used effectively prior to contract
award in such a way as to streamline the procurement process and
provide a head-start for the selection prime contractor in the
application and management of the subsequent SEP.
With the transition from traditional civil
service to agency status, the DRA has seen the need to introduce
a more professional approach to its major revenue earning
activities. This has been evidenced most clearly by the
commitment to achieve full ISO 9000 certification for the whole
Agency in a phased manner over the next several years.
The CIS (Command and Information Systems)
sector of the DRA was chosen to spearhead this drive, and
achieved certification in October '94 for all its business
streams, including systems and software engineering. This sector
was chosen both because of its exposure to these types of
activity and because of the perception that it could take the
lead in selecting, and developing where necessary, an appropriate
range of tools and methods.
This paper will discuss the development of the
resulting quality management system from a number of viewpoints.
Firstly, the technical standards themselves. The decision was
made early on to adopt the European Space Agency standard PSS-05
(now generally available in published from Prentice Hall) as the
core standard for all software projects, and to build around it a
number of supplements covering of topics important to the DRA's
business, such as prototyping, informal (laboratory standard)
software, commercial off the shelf software, and a number of
items necessary for compliancy with ISO 9000-3 (TickIT).
Particular languages and application areas with special needs are
supported by detailed work instructions, maintained by the DRA's
Software Engineering Centre. The resulting structure of the set
of procedures will be discussed, along with the reasons for the
choice of the ESA standard which has become pivotal to the
approach.
More recent work has led to the production, in
draft form, of an additional systems engineering procedures
document, which has the same level of abstraction as the ESA
standard but aims to generalise it to address systems comprised
of software, hardware and people. A supplement has also been
drafted to cover the issues of tailoring project lifecycles, that
is dealing with the large number of instances in which projects
do not comply with the simple 'waterfall' model, but adopt a more
complex lifecycle, for example iterative or evolutionary.
A further aspect which will be covered is that
of staff training and 'roll out'. Because of the timescales set,
this was necessarily compressed, but nonetheless successful. At
the time of writing, a survey is being conducted to ascertain the
opinions of staff as to the suitability and usability of the
procedures, and a second phase is being planned to accommodate
these points of view. Training has been an integral part of the
exercise, with large numbers of staff being put through a
specially designed 3-day familiarisation course, backed up by
more specialised training in particular tools and methods. A
training team, made up of DRA staff supplemented by outside
experts, has been put in place to service the demand, which now
extends potentially across the whole DRA.
Finally, the success of this project has
opened up the prospect of extending the software and systems
engineering practices developed so far to cover the whole DRA, a
move which can be expected to have far reaching implications not
only for the organisation itself but also for its principal
collaborators and customers.
This paper represents a summary of a 3 year
research programme carried out by 3SL. Issues that senior
management have in companies requiring and supplying large or
complex systems are discussed. The emphasis of the paper is to
compare and contrast the needs and expectations of different
industries.
Last Updated: Sunday, March 31, 1996