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