Fig Design.1: What is Design?
Fig Design.2: The Design Process
Fig Design.3: Systems Engineering and (General) Design Engineering for Complex Projects
Fig Design.4: Systems Engineering and Design Engineering for Simpler System/Equipment Projects
Fig Design.5: Systems Engineering and Design Engineering for Middling Complex System Projects
Fig Design.6: (General) Design Engineering
Fig Design.7: Worse Case Design
Fig Design.8: Statistical Design
Fig Design.9: Observations on Design generally
This chapter considers some concepts associated with the term ‘Design’.
Fig Design.1 is a general discussion of what a design is, ie. a paper/electronic description of something. The key question is how detailed does the description need to be.
Fig Design.2 describes, in very general terms, the process by which a design is produced.
Fig Design.3 considers the scope of systems engineering within the wider design process, and in particular differentiates it from more specific design engineering associated with particular types of product.
Fig Design.4 shows how the distinction between systems engineering and general design engineering is blurred for simpler systems/equipments, and the full gambit of systems engineering is not necessary. /P>
Fig Design.5 discusses the relationship between systems engineering and design engineering for middling complex projects, and the fact that it can be difficult to judge the amount of systems engineering that is necessary.
Fig Design.6 discusses in more detail what is meant by Design Engineering, in contrast to Systems Engineering.
Fig Design.9 provides some general observations relating to designs.
What is Design?
A design is a paper/electronic description of something that is theoretically realisable as a product. The description is in terms of the elements that make up the product. A complete description of the design of a product would uniquely define it, in that if there were two independent realisations of the item both fully conforming to the design description then they would look and behave in the same manner.
Note: Ultimately no two products are or can be literally identical. Failure events are at some level random and thus no two products would fail at exactly the same time. There are also tolerances associated with production processes, which mean there are small differences in what is actually produced.
For a design to be a complete definition it must be taken to a level where each element is itself either:
- Raw materials, ie. materials conforming to a known standard for that material, with the design then showing where this material exists within the product.
- Component parts, already available from suppliers, where each delivered component part would be identical within tolerances.
- A specification for an item, but where the specification includes all physical characteristics of the item including shape, interfaces, performance characteristics, etc.), in a completely unambiguous way and in a way guaranteed to lead to identical realisations. It is only feasible to write such specifications for components.
- An identification of a standard to which an item must comply, where this standard would lead to identical realisations. (Thus instead to
referring to a given suppliers component the design might specify a component conforming to a given standard. In this case however the standard must itself lead unambiguously to identical realisations for the component.)
- A clearly identified modification of any of the above.
Note that if raw materials or component parts need processing in any way in order for them to be used within the design, then the design description itself needs to future decompose them to a level where they do not need further processing.
Thus the definition of elements given here includes both equipments and minor parts such as pipes cables, connectors. It also includes the use of for example weld material, and any treating that might be required in order to for example bond elements together.
A defining characteristic of the level to which a design goes to is to a point where each item within the design exists without any reference to the design itself. The design then says something about how the item is modified or used within the system.
Thus for example:
- A valve might be shown within the design. This valve itself, assuming it is a general purpose valve used by others, is not particular to the given product. However where it exists within the product, and what it is connected to, is specific to the product and therefore is part of the design description.
- The product may have a metal box like structure. If this structure is a standard metal box available from a number of suppliers with for example a catalogue reference from the supplier, then the design merely needs to identify that it is that catalogued metal box. If any alterations are made to the metal box so that for example other items can be connected to it (eg. by drilling holes), then those alterations must be described as part of the design. If the metal box is to be specially manufactured from raw metal material then the detail must show the precise shape of the box after it has been manufactured.
The Design Process
As a design process it is impossible to simply jump from a requirement for a product to a complete detailed design description. The primary reasons for this are:
- A design, particularly a system design, may contain millions of items. It is impossible to get one’s mind around a large number of items.
- The interactions between component parts are complex and the interactions between component part characteristics and the whole product is impossible to visualise.
However there is a simple technique for managing complexity, namely viewing the items in a hierarchical manner. A design is therefore described in terms of a hierarchy of systems, sub-systems, equipments, and components.
These are not precise descriptions in that what one persons calls an equipment another person might call a system. This is because people work at different levels in the hierarchy. Someone working on a given system may view certain parts of that system as equipments, because they know they can go to a given supplier expert in that particular equipment area. The supplier for that equipment however may view it as a system since he is concerned with how that equipment is made up of simpler items which may themselves be what he sees as other sub-systems, equipments or components.
In grouping items into a hierarchy then clearly there will be interactions between the elements across the hierarchy. The process of grouping items into the hierarchy is largely driven by the need to ensure these interactions are in some way minimised so that design within a given hierarchical element can be undertaken independently with the interactions managed as ‘interfaces’. Different organisations are skilled at working at and supplying products relating to different ‘product’ areas.
Thus there are organisations that supply components, which can be used in many equipment/system products. Because these components are both simpler and have been widely used their performance and potential interactions with other components are well understood.
There are organisations skilled at producing given equipments. These will use components, fix them to structures (eg. a metal casing), and connect them together, and produce a more complex entity. Certain equipments or types of equipments will be widely used and again their interactions with other entities will be well understood, though maybe not completely so. Some equipments are uniquely designed for a given purpose and may there may be interactions which are not fully understood.
Putting equipment together to form systems varies from the production of mass produced systems such as aircraft, to unique systems such as a power plant or an aircraft carrier. Where systems are mass produced then consideration information emerges over a period of time about interactions. In the case of unique systems then far less information exists.
The above is further complicated by the fact that whilst all interactions are ultimately due to well known physical phenomenon, eg. mechanical or electromagnetic, the precise realisation of the interaction is dependent upon the detail of what is produced, ie. for example upon the distance between components. And because production processes are not precise then one realisation of a design might lead to slightly different distances between components than another realisation. And this difference in distance may be sufficient to have one realisation behave differently to another realisation. Another example of how differences might occur is in a welding activity.
Systems Engineering and (General) Design Engineering for Complex
This then brings us to being able to differentiate between what is termed System Engineering from (General) Design Engineering. Systems Engineering is primarily about the process of managing interactions between different elements at a given level in a hierarchy, and across the elements in that hierarchy. System Engineering techniques are about the management of complexity, and complex systems are too complex for individuals to be able to grasp the full design. However Systems Engineering techniques do not of themselves produce good designs. They ensure the effective management of system projects, and they prompt for ensuring that all issues are addressed. An important part of good design however is making good trade-off decisions early in the project. The system design process leads to a gradual hardening of the design such that there becomes less scope for high level changes as the project progresses. This means that the consequences of decisions, including in Opportunity Cost terms (ie. could we have made a better decision, or should we have made a change when we had the opportunity) must be recognised very early on.
(General) Design Engineering is about understanding what physical interactions exist. It is about
the ability to apply traditional ENGINEERING skills and understanding to the high level design process, particularly when looking to arrive at
a System ARCHITECTURE. The need for General Design Engineers is not so much in being able to assess the consequences of a given decision, the System Engineering process is capable of ensuring a given decision is fully assessed, but more in terms of being able to generate ideas in the first place – see
It should be noted that the concept of (General) Design Engineering as described here is not Design Engineering for a particular product, but is an ability to apply an understanding of Engineering to designs in general. Engineers able to do this are probably few and far between, nevertheless projects need to recognise that such a skill can be invaluable.
A lack of understanding of the above leads to much confusion within the engineering world, and leads which ultimately leads to people being given jobs to which they are not suited. The following are a couple of examples:
- Good (General) Design Engineers are assumed to be automatically good Systems Engineers. Yet this
handbook should have clearly shown that Systems Engineering and Design Engineering are very different disciplines and whilst as individuals certain talented engineers may be able to move from (General) Design Engineering to Systems Engineering, they do
require training and understanding of what Systems Engineering is about.
- Good Systems Engineers are assumed to be able to do Design Engineering. Fig
Design.6 clearly indicates that Design Engineering requires an understanding of basic engineering in a way that Systems Engineering itself does not. Good Systems Engineers will generally ensure that Design Engineering is done, but will not necessarily have the skills to undertake it themselves.
Ultimately Systems Engineering must take responsibility for ensuring (General) Design Engineering is undertaken, just as it must take responsibility for ensuring other specialisations such as Human Factors, or Shock engineering is undertaken. However the skills required to undertake Systems Engineering are not the same skills as used to undertake (General) Design Engineering.
Clearly it might be of benefit to have persons that are both good Design Engineers and Good Systems Engineers. However for large systems this is
generally not feasible. Both Systems Engineering and Design Engineering are full time jobs and it would not be feasible to have one person responsible as both
Chief Engineer/Designer and Chief Systems Engineer. For simpler systems this would be feasible – see below, and part of the reason many big projects have difficulties is that they do not fully appreciate the complexities and organise themselves accordingly.
Systems Engineering and Design Engineering for Simpler
As one deals with relatively simple system and equipment projects then the need for the full gambit of systems engineering techniques diminishes, since it becomes possible for individuals to understand the full design. Design Engineers are able to understand the full interactions, and the role of Systems Engineering becomes more one of maintaining configuration control and traceability of information.
Systems Engineering and Design Engineering for Middling Complex
There is a significant problem with middling complex projects since it is unclear as to whether Systems Engineering should take the lead in managing the technical interactions or whether given Design Engineering engineers are able to take responsibility for the integration of the design.
The unnecessary application of system engineering techniques can make the project over
bureaucratic, particularly if the systems engineers are not able to tailor their techniques to the particular needs of the project.
However if the complexities are not fully appreciated and design engineers are left to run the project in traditional means then many interactions may not be fully appreciated and opportunities for change missed.
(General) Design Engineering
Design Engineering is about understanding the detailed interactions that might go on between different parts of a design and:
- Being able to judge whether problems are likely to arise as a result of the design, and providing an engineering input into the resolution of problems.
- Being able to innovatively identify improvements or better ways of doing the design.
Many potential problems will be captured as a part of any systems engineering led project. Systems Engineering will ensure that the design takes cognisance of the different viewpoints in a managed way. Thus there should not arise problems due to incompatibilities, for example of interfaces. The design will be reviewed from the
viewpoint of many cross system disciplines such as electromagnetic compatibility, safety, supportability, etc. However there may be interactions which do not fall neatly into any of these
categories. There may also be interactions between sub-systems which are not fully appreciated by the sub-system designers. It may also be that the individuals tasked with some of these responsibilities may not have a full understanding of the interrelationships. Design Engineering is the general discipline for picking up and ensuring cognisance is taken of any potential engineering interactions which are not being fully addressed elsewhere.
The real benefit of Design Engineering however is being able to see the bigger design picture and identify opportunities for improvements. Without this whole system traditional engineering viewpoint many opportunities will be missed.
Worse Case Design
Underlying any design are the situations and scenarios it is intended to be used in. A worse case design is one which is intended to function fully under worse case conditions. The term could apply to certain aspects of the design rather than the design as a whole.
With respect to many systems it is impractical to ask it to cope with worse case situations. An anti-missile system for example might be required to prevent missiles hitting a target. Using current day type technology however there will always be scenarios where it will fail; for example simply keep increasing the number of missiles. The system can therefore only be designed to have a given success rate in given situations/scenarios.
The situation where worse case is often believed to apply is with respect to Safety. However even here there is a practical view taken of what are worse case conditions. It is always possible to identify situations which are ‘worse’ than any specific situation. For example a meteor strike.
Statistical Design involves thinking of parameters as having statistically distributed performance values, and carrying out analysis accordingly.
Using statistical design parameters are required to be within given
tolerances. Thus, rather than attempt to cope with a worse case situation the situation only has to be coped with for a given percentage of the time, typically 95%.
In statistical design detailed investigation is required to identify the mix of
tolerances for lower levels which best give the tolerance required at the higher levels.
Statistical design usually possible whereas worse case design is frequently impractical.
Examples of statistical design include:
- manufacturing tolerances
- voltage tolerances
- effectiveness given as a percentage
Observations on Design generally
- No design is ever complete, in that with extra effort additional modifications and improvements can be made.
- The longer the time spent on design the less the increase in value of the design, unless a technological breakthrough is made. Design effort must be carefully managed.
- Few designs are entirely novel. They build on known designs.
- Designs are a balance between innovation and standardisation. The preferred
design is one that already exists and meets the requirements and constraints. If such does not exist then in general the
preferred solution is that which is a minimum change from an existing design. However the production of a design which is a minimum change should not become an end in itself, because this will lead to lack of effort on understanding the underlying requirement, and will lead to lack of innovation.
- Many design engineers are constrained in their thinking by lack of appreciation of wider engineering issues. Many product design areas would benefit from time to time from having highly
competent engineers from very different fields being involved in some of their product developments.
|Last Updated: 17 October 2000