-
SYSTEMS ENGINEERING
MOOC 6 PRELIMINARY AND DETAILED DESIGN
PART 1The previous stage (conceptual design) has resolved what
the business stakeholders want from the system and what the key
stakeholders think the system needs to be able to do in order to
deliver thatcapability to the business.
The key stakeholders have articulated their understanding of the
system level requirements in order to explain what the system needs
to be able to do, how well it needs to be able to do it, under what
conditions it needs to perform and what other systems are involved
in its performance of those functions. Additionally, the key
stakeholders have decided how the function and performance of the
system will be proven by describing verification approaches for
each of the requirements.
The stakeholders will have identified viable systems level
solutions to their requirements and weighed up the pros and cons of
each of the options. It is critical to remember that the pros and
cons will include not only the solutions ability to meet function
and performance requirements. Considerations need to take account
of procurement issues such as cost, schedule and risk, lifecycle
issues such as sustainment and disposal costs, and capability
considerations such as training, personnel and organisational
issues. Based on this complex and interrelated set of
considerations, the stakeholder group will have made a decision and
chosen a preferred solution. If this solution is being provided by
an external organisation, a contract will have been negotiated
between the organisations. To differentiate, we will refer to the
organisation who needs a solution as the customer and the
organisation providing the solutionas the contractor. The contract
can be thought of as adescription of respective responsibilities
and risk allocation.
If the solution is being provided by in-house resources, systems
engineering practise would still highly recommend a contract-like
agreement between the in-house customer and the in-house solution
provider (in order to document the requirements for the solution
and agreement
1
-
between the parties).
Either way, once we have the agreement sorted out, we concluded
conceptual design with a review of requirements and proposed
solution just to confirm our readiness to commence the more
detailed designactivities.
We are about to embark on a process that will see our logical
solution (that is, a thorough understanding of what we want to
achieve) translated into a physical solution (that is, a real and
usable solution). It it important to note that I am not suggesting
that the solution needs to be physical inthe true sense of the
word. A piece of software, for example, is not something we can
touch or weigh or feel but it may be a usable solution to a
problem.
In this module, we will continue to use the house example so
this will be a physical solution in the true sense of the word and
in a systems engineering context.
At the conclusion of the conceptual design phase, it is highly
likely (probably essential) that the designers of the preferred
solution would have at least a preliminary idea of what the
proposed solution was going to look like.
They would have a good idea of how the system will be broken
down into system elements (or subsystems), roughly how each of
those elements will contribute to the overall solution and how
those elements need to interact (or interface) with one
another.
For example, we would expect the designers of our house to know
that it will have an electrical subsystem and will require a
plumbing & drainage subsystem. We would also expect to know
that the house would have bedrooms, living areas, a kitchen and
bathrooms. We probably also expect to have draft drawings and plans
available at this stage to show us the conceptual design for the
house.
The aim of preliminary design is to look in more detail at each
of those subsystems and determine what each of the subsystems needs
to do in order to collectively satisfy our stakeholders (or, in
this case, the people who will own and/or live in the finished
2
-
product).
To perform preliminary design, we perform a requirements
analysis and allocation process. We tend to start with an
understanding of the subsystems (as discussed above) and then look
to understand what requirements each of those subsystems needs to
meet in order for the system to achieve its requirements. We will
end up with a hierarchy of requirements; system requirements
leading to subsystem requirements. Lets look at an example. Assume
we have a requirement at the system level that promotes
environmental friendliness of our design. It is likely that this
system level requirement would lead directly to a requirement for
rain water to be collected and used within the house system.
Logically, rain water harvesting, storage and use would be
allocated to theplumbing and drainage subsystem. The same system
level requirement may lead to the need to convert sunlight into
electrical energy for storage and use in the house or even sale
back to our energy company. This set of subsystem requirements
would be allocated to the electrical subsystem (and may lead to
previously unknown requirements such as the need to interface to
the energy company in a certain way.
As we are going through this process, we maintain traceability
within the requirements hierarchy so thatwe always know where our
requirements have come from. In systems engineering, people often
talk about forward traceability and backward traceability to give a
feel for which direction within the hierarchy we are talking about.
Forward traceability is from thesystem level requirements to the
subsystem level requirements. By ensuring forward traceability
exists,we can show our stakeholders that we have listened to all of
their requirements and all of their requirements are being
accounted for somewhere within our design. Forward traceability is
also very important when trying to deal with changing requirements.
For example, using the previous example, if the stakeholders
decided that environmental friendliness was no longer required, we
would be able to trace that requirement to the rain water
harvesting requirements in the plumbing and drainage system (and
equivalent electrical requirements) and remove them from our
consideration.
Backward traceability is used to show how particular subsystem
requirements relate to system level requirements. Backwards
traceability helps us to show that all of our subsystem
requirements are there for a reason (i.e. to contribute to
system-level function or performance). It helps us avoid what
is
3
-
often called requirements creep where our requirements
progressively get more and more capable than they need to be.
Although this sounds like a good thing, requirements creep
progressively takes our system away from where it was intended
tobe. It can end up costing more than it needs to and taking longer
to realise. Also, when subsystems are competing with the same
finite resources, requirements creep can cause some subsystems to
exceed their requirements whilst others are left struggling. In
these cases, we may end up with a system that exceeds some function
and performance requirements whilst failing others. In systems
engineering, we are interested in meeting all of our requirements,
not exceeding some and failing others.
An example might be the design of a motor car and the finite
resource might be power from the engine. If we let the
air-conditioning subsystem requirementscreep so that the
air-conditioner ends up having requirements that far exceed what it
needs to do, wemay end up with an air conditioner that uses more
than its fair share of energy from the car. We may end up with the
engine needing to work harder and therefore using more fuel. In
this case, we will have acar with a fantastic air conditioner and
terrible fuel economy where what we were really after was a car
with an adequate air-conditioner and acceptable fueleconomy.
Backward traceability is important in protecting us in these
sorts of situations. Backward traceability also helps us if we
discover that one of our subsystems is not able to meet its
requirements. We are then able to use traceability to find out what
system level requirements are at risk.
Another task that we need to perform during this process is the
identification of interfaces that need toexist within our system
and between our system and its external environment. Remember these
external systems are outside our boundary but we still need to
interface with them if we are to be successful. For example, our
plumbing and drainage subsystem will need to receive an input from
the domestic water supply and provide an output to the domestic
sewerage system. These are examples of external interfaces. We
identified these during conceptual design. During preliminary
design, we also need to identify internal interfaces. For example,
we may designate the kitchen as a subsystem. The kitchen subsystem
will need interfaces from the electrical subsystem and the plumbing
and drainage subsystemin order to perform its functions as a
kitchen. Interfaces come in many forms. For example we...
4
-
...might need to define physical interfaces like pipes and
wires, electrical interfaces like voltage levels, hydraulic
interfaces like water pressures and electronic interfaces such as
communications signals.These interface requirements are critical to
us and will place additional constraints on our subsystems sothey
are identified and defined during preliminary design so we can take
account for them when we perform detailed design.
By the end of all of this work, we will know what all of our
subsystems are, what each of those subsystems needs to be able to
do and how those subsystems interface or relate to one another. It
is now time to make some design decisions.
PART 2When we look at each of the subystems in our system, we
will need to make some decisions on howwe are going to proceed in
order to realise them. Broadly speaking, we have 3 options. In some
cases, we may be able to go to the market and purchase thesubsystem
off the shelf, sometimes an off the shelf option needs to be
modified in some way before being suitable and in other cases there
are no off the shelf solutions and we need to develop a solution
from scratch.
Lets start by looking at off the shelf solutions. Using our car
example from earlier, if the engine was a subsystem in our car
design and we knew exactly what the engine needed to be able to do
from a function, performance and interface perspective, chances
are, there would be some commercially available engines that would
fit the bill.
Commercially available subsystems offer a number ofadvantages to
us. They are likely to be known in terms of their function and
performance. That is, there is likely to be some objective evidence
in existence that the subsystem does, in fact, perform inaccordance
with the claims. Off the shelf items are likely to be immediately
available or available with some known lead time making planning
much easier. Their costs are also going to be a known quantity.
Thinking lifecycle for a minute, they are likely to have existing
support systems such as tooling, test equipment, spares, training
and maintenance
5
-
support in place. These are all advantages of off the shelf
options, however there are some other things to think about. The
technical documentation associated with Off the shelf systems is,
in my experience, something to look out for. If we are goingto use
off the shelf subsystems, we must have access to appropriate levels
of technical detail to allow us tointegrate the subsystems, test
and operate them and train people in their use. If the
documentation is unsatisfactory, then this must be considered when
making design decisions. We also need to watch out for
obsolescence. We need to take account of the technology used in the
off the shelf items, market size and technology stability. It is
quite possible (in fact I have experienced it) for off the shelf
subsystems to become unsupportable if they becomeobsolete or the
commercial market disappears for some reason.
In some cases, we may come across an off the shelf option that
is almost suitable for consideration but lacks one or two key
attributes. If an off the shelf option is close to meeting our
requirements, it may be possible to consider using the off the
shelf option and developing a modification to make it more
suitable. Modified off the shelf items have many of the same
advantages as pure off the shelf options but we need to be careful
about things like warranty and support agreements. Making changes
to an item after it has been procured may render agreements
invalid. If we are to modify an item, we will need to consider the
modification a detailed design task and develop the modification in
a controlled manner. We will discuss detailed design next. One
other point to note about modifying off the shelf items. In my
experience, people tend to drastically underestimate the effort
associated with modifying off the shelf items. They also tend to
assume that critical enablerslike detailed design data for the item
will be available. The point is the be careful not to underestimate
how much time, money and effort willbe involved and ensure that
enablers like detailed design data is available prior to making
decisions about modifying off the shelf items.
If there are no off the shelf items available to us, we may need
to consider designing and developing the subsystems from the ground
up. Naturally, this will be an involved process which we will
discuss soon but remember also that we will need to think about
lifecycle issues and ensure that we establish through-life support
for anything that we design Systems engineers need to work closely
with our integrated logistics support colleagues during this period
to ensure that our design is manufacturable, supportable and
disposable. More on that later. A keyadvantage for the
developmental approach is that
6
-
theoretically we should end up with the perfect solution to our
requirements. Unfortunately, I have some bad news about that.
Another observation from my experience is that sometimes people
will reject an off the shelf option that is not quite perfect and
go down the developmental path. After a long time and a lot of
money, they may end up with a developmental solution that is
further away from perfect than the off the shelf option they
rejected a long time before. Apart from the function and
performance shortfall, it would have taken them (andtheir
stakeholders) a lot of time and a lot of money tofind out. Please
be sure that the developmental approach is definitely the way to go
before proceeding down that path.
When we are looking at our subsystem design, it is rare that we
will happen on the best answer straight away when it comes to how
to design our subsystems. We need to make sure that our subsystems
are going to perform in accordance with the requirements that have
been allocated to them but we also have to make sure that when all
of these compliant subsystems are plugged together that we will end
up with a system that meets all of the system level requirements.
We need to explore and exploit any room to move with respect to our
subsystems so that we arrive at the best possible answer. Sometimes
this process is referred to as making optimal use of any design
space available to us.
Please note carefully that just because we refer to this as
design space does not mean that the concept is applied only to
trade-offs involving physical space. The space we are referring to
is room to move. It might relate to bandwidth in a communications
system, processing power in a real-time computer system, electrical
power, physical space, weight and so on.
Lets go back to the car and the air-conditioner to illustrate
this point. Lets say the weight of the car needs to be no greater
than 1,225 kg. This may be a system level requirement in the form
of a constraint. During the preliminary design, the systems guys
will make some decisions about how much of this 1225 kg each of the
subsystems will be given. For example,we might allocate 200 kg to
the engine, 25 kg to the aircon and 1,000kg distributed amongst the
rest of the subystems on the car. There will be other system-level
constraints assigned to these two subsystems such as physical size
constraints but for this example, the weight constraint is enough.
Naturally the engine
7
-
will have a whole lot of other system level requirements
allocated to it that will result in derivedrequirements. For
example, a derived requirement for the engine might specify how
much power the engine needs to be capable of delivering (to power
the car but also to power other systems like the air-conditioner).
Similarly, the air-conditioner will have other requirements
allocated to it such as how much power it is allowed to consume in
keeping the car at a certain temperature under certain
environmental conditions.
If we give the air-conditioning experts all of their
requirements and we give the engine experts all of their
requirements and leave them to it, they will develop their own
subsystems independently of eachother. The air-conditioning people
will come up with a great design that is able to use all of the
power and weight allocated to them to create an
air-conditionerdesign that may exceed their requirements. The
engine people will do their best to do the same. This sounds good
because we will end up with a car that meets it air-conditioning
and engine requirements aswell as the overall weight
requirement.
But what if the engine designers are struggling. They might be
able to build an engine that meets all of therequirements but it is
too heavy or fails to deliver quite enough power. It would not make
sense to allow this to happen if the air-conditioning team were
able to meet their requirements with room to spare. Consider for
example if the air-conditioner could be designed to be slightly
lighter than the allowed 25kg and still meet all other
requirements. If the air-conditioner could be designed to be only
20kg, the systems engineer could allocate that spare 5kg to the
engine team and allow them to design an engine that is 205 kg.
Overall, the car will still weigh 1225kg but we will end up with an
adequate air-conditioner and an adequate engine in the process.
What if the air-conditioner design was not only lighter by 5kg but
also consumed less power from theengine than initially thought. Now
the engine does not need to produce as much power as previously and
can weigh 205kg. By using some of the design space available from
the air-conditioner, we have given the engine designers much needed
room to move.
What we end up with is an adequate air-conditioner and an
adequate engine that when integrated together are able to deliver
the required system levelperformance. If we are not careful, we
could have ended up with a fantastic air-conditioner coupled
8
-
with a marginally compliant engine which integrate to deliver a
car that is underpowered and overweight.
In systems engineering, we would much prefer to deliver a system
that meets all of its requirements rather than a system that
exceeds some requirements and fails others. To do this, we must
keep an eye on any design space available to us and make sure we
are making best use of that space.
Eventually, after a lot of work, we will have decided what all
of the subsystems are, what they need to do,how they will
interrelate with each other and how we will go about designing
them. We will also be ableto show how the subsystem design
contributes to and supports system level requirements. We will have
thoroughly explored design options and any available design
space.
We will document all of this information in the form of
subsystem specifications and design decisions and rationales. Once
this has been completed, we will stop, draw breathe and have a
design review. This design review is normally called the
Preliminary Design Review or PDR. At this review we look at all
ofthis information and confirm that we are ready to proceed to
detailed design. We will also ask the decision makers to justify
some of their decisions by asking questions like When you came up
with this option, what other options did you look at? What were the
relative merits of the different options? Have you considered
lifecycle issues like manufacturability, maintainability and
disposability inyour decision making. These are all good questions
that are simply looking to confirm that the design decisions made
during preliminary design are robust and defendable decisions.
After all we are spending alot of time and effort on this exercise
and will want tomake sure (as best we can) that we are going in the
best possible direction.
Once the design review is completed for each of the subsystems,
we can move onto detailed design.
From our PDR we have confirmed decisions about how each of the
subsystems will be realised. Some will be procured off the shelf,
others will be modified and others will be designed from scratch.
The subsystems that are to be modified or developed from the ground
up will need to go through detailed design activities. Even those
subsystems that are procured off the shelf will need to be
integrated to...
9
-
...form the system. That integration effort is also part of the
detailed design process.
At the end of the detailed design process, we need tobe certain
that we have a design that meets all of therequirements set for the
system by our stakeholders, can be
manufactured/produced/constructed, can be supported or sustained
throughout its operational life and can be disposed of when the
lifecycle comes to an end. We have a lot of work to do.
If we considered the next phase in our lifecycle whichis the
production and construction phase, we get a hint as to what needs
to be done during detailed design and development. If we are
dealing with hardware (which is defined here as anything that is
not purely software) we have to come up with the detailed design of
the subsystem but we also need tobe able to specify how it is to be
built. This description includes parts lists, materials
descriptionsand specifications, and construction and fabrication
processes. After all, the parts, materials and construction
processes will impact heavily on the function and performance of
the system and therefore need to be carefully considered, designed
and specified.
Detailed design is a tough job and is the job that is
traditionally associated with professional engineers. Professional
engineers are expected to be able to take a specification and
determine a solution that meets those requirements.
We will not cover professional engineering here but it is
important to emphasise that detailed design is an iterative
process. We design, build, test, learn and repeat the process. We
do this over and over until weare satisfied with the result.
Professional engineers will use plenty of tools to help them do
this. Some of the common tools used include prototyping, modelling,
simulations, and reusing similar designs that exist elsewhere.
For example, consider that we are trying to come up with the
detailed design of our kitchen. It is unlikely that this design
will be done only on paper. We will need to consider the work flow
in a kitchen so that the kitchen works as a kitchen. For example,
we would not want to put the fridge on the opposite side of the
kitchen from where we prepare food. We would not want to put the
dishwasher a long way from where our cutlery and crockery is
stored. We need to consider where services from our other
subsystems such as cold water, hot water, gas,
10
-
drainage and power can be provided. Should the kitchen design
constrain the electrical and plumbing subsystems or should the
kitchen be constrained? In all likelihood, it will be a bit of both
but these are the sorts of things we are thinking about in detailed
design.
Coming back to the kitchen, we will go and see other kitchens in
showrooms and display homes, we will probably make use of software
tools to produce layout drawings to explore things like workflow,
we will select major components in the kitchen such as stoves,
ovens, sinks, dishwashers and so on.
We go through this process with all of the subsystems in our
design and confirm that the integration of all of the subsystems is
going to work for us at the system level.
Once we have completed this process and documented the results,
we are ready to do a final review prior to construction and
production. We will call this review the Critical Design Review or
CDR. The role of CDR is to confirm that the detailed design is
complete and has been appropriate documented. We will ask similar
questions to what we asked at PDR albeit at a different level of
focus. We will be looking for evidence that the design process has
been rigorous such as consideration of design alternatives,
selection of preferred approaches for sound reasons, solid
documentation discipline and readiness for construction and
production.
11