SYSTEMS ENGINEERING

MOOC 7 PRODUCTION, UTILISATION & DISPOSAL

PART 1
Our previous work completed in detailed design has
provided us with a suite of design artefacts that will
support construction and production. We have
detailed design documentation such as drawings and
software design documents but we will also have
detailed parts lists, materials specifications and
process specifications to explain how to produce and
construct our system.
In parallel with the preliminary and detailed design
process, our production specialists and integrated
logistics support specialists will have been working
with our engineers to ensure that the design is in fact
realisable. They will be planning the production and
construction effort in order to address key issues
such as plant requirements and specialised
equipment requirements. For example, in
construction our house, we may need to ensure
earth moving equipment, concrete mixers and
pumps and so on are available when we need them.
The specialists will also be looking after long lead
time items that are part of our design to ensure that
these items are ordered in a timely fashion in order
to have them available as they are needed. For
example, if our design makes use of special material
like imported tiles or floor coverings, we may need to
order these items in sufficient quantities well in
advance of the construction starting. We may need
to store these items in a warehouse or storage facility
in sufficient quantities to support the build. Things
like shelf life and storage conditions will then become
a consideration. The construction planning will also
need to take account of specialised human resources
required during the construction. In our example, the
list of specialists is long from equipment operators,
concreters, plumbers, gas fitters, carpenters, roofers,
electricians, cabinet makers and so on. These
resources need to be organised to be available with
the appropriate skills and experience at the
appropriate time. This all takes planning and
management.

From a systems engineering perspective, the ability

to influence the direction that the system is taking is
now rapidly reducing. Making changes at this stage in
the process will be very expensive indeed if possible
at all. Systems engineers are now generally more
interested in confirming that the design, as specified,
is in fact being realised. A major systems engineering
task during this stage is to work towards system level
verification by confirming that the as-built system is
meeting its specified requirements. We can do this in
a variety of ways but is generally a combination of
inspections, analyses, tests and demonstrations.

Lets look at some examples of each:

Inspection: If we needed to verify a given layout
requirement had been met in our kitchen, we would
probably simply inspect the kitchen to confirm this.
Analysis: If we needed to verify that the electrical
system was able to safely interface with the mains
power, we would want to confirm that the installed
switchboard had been previously approved for this
sort of task. We may do this by analysing the
documentation and certificates that came with the
switchboard used in our electrical system.
Test: If we wanted to confirm that hot water was
delivered to every tap within x seconds of turning
on the tap, we may use test equipment (like a stop
watch and a thermometer) and an agreed test
procedure to measure the time it took for hot water
of a given temperature to be delivered.
Demonstration: If we wanted to check that all of the
lights were working, a simple walk around and
demonstration of the lights may be sufficient.

Configuration audits are used to confirm that we

have an accurate description of the as built system.
There are generally two types of audits conducted by
systems engineers; functional audits and physical
audits. A functional configuration audit makes heavy
use of verification results discussed previously to
confirm that the systems functionality is accurately
reflected in the systems documentation. By
completing the functional configuration audit, we
can be confident that our documentation accurately
describes the function and performance levels of our
system. A physical configuration audit confirms that
the physical description of the system is consistent
with the as built item. This ensures that we are
certain of the things like materials and parts used in
the construction and layouts of things like interfaces.
The critical point to note, especially with physical
audits is that they can often only be done during
construction and production, not afterwards. For
example, a physical audit of our house will confirm
that the drawings of things like stormwater and
sewerage connection is accurate on the drawings.
Really the only way to do this is to walk around the
block of land and confirm that the location of the
pipes in the ground is as per the drawing. This needs
to be done when the trenches are still open and an
inspector can see the pipes in the ground. The
inspector is then able to correlate what he or she
sees on the ground and what he or she sees in the
drawings.
For example, here is an image of an established
garden bed, under which lies buried storm water
pipes. I recently needed to locate that stormwater
pipe so I could finalise an irrigation system in the
garden. If I was not certain of where the stormwater
pipe was, I would need to dig around in the garden
until I found it. This digging would damage the
established garden and potentially cost a great deal
of money to repair. Fortunately, when the house was
being constructed, I walked around with the plumber
and the drawings and confirmed correctness and
added dimensions. I was conducting a physical
configuration audit of the plumbing . When it came
time for me to locate the stormwater pipe, I simply
dug a hole where the marked-up drawing indicated
and there was the pipe. I was not surprised to find
the pipe because I was certain of its location (via the
physical configuration audit).

As we are progressing with construction and

production, we will need to revisit those lifecycle
concepts that we established way back in conceptual
design. This will help us transition the system to
operational use by our stakeholders. Issues that will
need to be finalised and activated will include the
facilities that will house the system and its associated
support system, the personnel who will use and
support the system, any training systems that will be
used to train our users and support personnel, the
maintenance and engineering support system
including associated support equipment,
consumables and spare parts, and of course the
operating procedures that will be used to guide users
in the operation of the system. Once these enablers
are in place, we will be ready to transition the system
into operational use.
PART 2
Once the system is in operational use, it will be used
within its external environment to close the
capability that defined the need for the system in the
first place. Support will also be provide to the system.
It is common to think of support in some form of
hierarchy. We have used the words Operational,
Maintenance and Engineering support to
describe this hierarchy.
Lets use our house example to explain.
When you live in a house, there is always something
that needs to be done. We sweep the floors, clean
the bathrooms and keep the spider webs at bay. We
might even need to change the odd light bulb or
washer in a dripping tap. These are activities that we
expect the users to be able to look after in order to
keep our house running smoothly. These are
examples operational support activities.
In the longer term, we might need to repaint our
deck every year just to protect it from the weather
and we might need to clear the gutters of leaves
every Autumn. We would consider these routine or
preventative tasks to be examples of maintenance
support. Sometimes we would need to get expert
support for things like an electrical problem or a
sewerage blockage. Even though we need external
help with these issues, they are still maintenance
activities because we are not changing anything
about the house, we are simply maintaining it.
Sometimes, though, we need deeper support. We
have called this category Engineering support
because the deeper support often involves making
changes or upgrades to the system. Engineering

support needs to be established with the system. It is

not something that we can assume will be in place
automatically. Ensuring all of our engineering and
design documentation is correct during the detailed
design and construction and production phases will
be an important part of enabling engineering support
into the future.
This leads us to a discussion of modifications.
Modifications to our systems during the utilisation
phase are almost inevitable. Users will suggest new
requirements, our environment will change,
technology will change causing us to address
obsolescence and so on. Modifications are a
reinvigoration of the systems engineering process.
A modification is like a mini systems engineering
process all over again. Where possible, we should try
to build expandability and upgradeability into our
systems to support future growth and modifications.
Some examples in our house might include a house
being designed for a small family with the
expectation that children will follow and the house
will need to be extended, a house being designed to
allow the addition of autonomous accommodation
for an aging relative in the future, or anticipating that
our carport might one day become a lock up garage
with a workshop and shower. If we take account of
these possibilities during the design and construction
phase, we will have much more flexibility in
incorporating these upgrades in a cost effective
fashion in the future.
Ultimately, all good things come to an end and
disposal of our system is required. Disposal of our
system is normally brought about for one of a few
reasons.
Maybe we no longer have a need for the system and
we therefore dispose of it. Our house might become
too big for us as children leave home leading us to
decide to sell it and move to a smaller place.
Sometimes our systems start becoming too difficult
to maintain and support leading to a decision to
dispose of it. Again our house could be an example of
this. Maybe our house is a multi-storey house and it
becomes too difficult to get up and clean the upper
levels of the house. Maybe the house is a heritage
listed property that needs to be maintained in
particular way using particular materials and the
skills and materials are becoming increasingly
difficult to source.
Of course there could be many reasons why a
decision is made to dispose of a system. The disposal

options are also wide and varied. We have discussed

the idea of on-selling our house. Selling a system to a
new organisation is certainly one of the disposal
options available. Sometimes our systems are
disposed of by destruction or scrapping. We have all
seen examples of old buildings being knocked down
and destroyed. It is possible some some recycling of
parts or materials may occur when a system is
disposed of in this way.
Sometimes we may retire a system from one role
(disposal as far as that role is concerned) but use it in
a different role. For example, in my experience in the
aerospace industry I have seen old aircraft taken out
of operational service and reused as training aids. I
have also been involved with old aircraft being taken
out of operational service and being used as museum
pieces. In these cases, the end of one lifecycle
(operation service) marks the beginning of another
(training aid or museum piece).
We need to wary of classic disposal issues such as
hazardous materials, sensitive or classified
information and environmental constraints and laws
when making disposal decisions.
Once a system has been disposed off, the lifecycle of
that system has concluded.