-
SYSTEMS ENGINEERING
MOOC 7 PRODUCTION, UTILISATION & DISPOSAL
PART 1Our 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 factrealisable. 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 toorder these items in sufficient quantities well in advance
of the construction starting. We may need to store these items in a
warehouse or storage facilityin sufficient quantities to support
the build. Things like shelf life and storage conditions will then
becomea consideration. The construction planning will also need to
take account of specialised human resources required during the
construction. In our example, thelist 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.
1
-
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 inthe 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 ina 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.
2
-
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 bysystems 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
plumberand 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).
3
-
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 associatedsupport 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 usersin the operation of the system.
Once these enablers are in place, we will be ready to transition
the systeminto operational use.
PART 2Once 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 thefirst 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
4
-
support needs to be established with the system. It isnot
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 supportinto 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 thatour 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
constructionphase, 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 ofthis. 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
5
-
options are also wide and varied. We have discussed the idea of
on-selling our house. Selling a system to anew 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 ina 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 museumpieces. 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.
6