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