Selected topics from systems engineering#
In essence, Structured Electronics Design is a systems engineering approach to analog electronics design. There exist many different definitions of systems engineering, the one below is taken from https://en.wikipedia.org/wiki/Systems_engineering :
Definition
Systems engineering is an interdisciplinary field of engineering and engineering management that focuses on how to design, integrate, and manage complex systems over their life cycles. At its core, systems engineering utilizes systems thinking principles to organize this body of knowledge. The individual outcome of such efforts, an engineered system, can be defined as a combination of components that work in synergy to collectively perform a useful function.
In this section, we will briefly summarize some topics from systems engineering. In section Basic concepts, we will introduce some basic concepts, such as innovation, development, research, the invention, the product life cycle, the hierarchical organization of the design process, and the idea of considering a design process from a risk management point of view.
In section Basic design process we will present a basic design process that can be used at any hierarchical level of the design.
All sub-processes of this design process result in various kinds of data. Design documents are views upon this data, captured over time. In section Design data and documents, we will describe these results in more detail.
Basic concepts#
Innovation#
Innovation can be defined as a process in which the implementation of new ideas results in new markets, new technologies or new products.
Product, market and technology development#
Mature companies innovate by developing only one of these three at a time:
Market development:
Development of new markets for existing product-technology combinations
Technology development:
Development of new technologies for existing product-market combinations
Product development:
Development of new products for existing market-technology combinations
Simultaneous development of combinations of the above is called diversification. Diversification is considered risky. In practice, it has a very low success rate.
Innovation plans are often presented in road maps. Such maps illustrate the successive development of products, markets, and technologies over time.
Research#
Research is a process in which one acquires knowledge about something. It must be separated from innovation. Knowledge about products, markets, and technologies, is the basis for their development, and missing knowledge must be identified and acquired before starting a development that needs it.
The invention#
The innovation process in start-ups usually differs from that in mature companies. The latter ones have a well-defined product-market-technology portfolio and innovate by improving or extending products, markets, or technologies. Start-ups often start with a basic idea based on a discovery or an invention, while they don’t yet have a well-defined product-market-technology portfolio. The source of the invention can be a dream, an annoyance, something that somehow pops up in the mind of an engineer, but in many cases also: the result of a structured design process!
Product life-cycle processes#
In this book, we confine ourselves to the design of application-specific amplifiers. One important aspect is to determine the requirements of such amplifiers. In general, the product requirements follow from the interests of the stakeholders of the product life cycle processes. Fig. 1 shows an IDEF0 model of the product life cycle processes.
The IDEF0 drawing convention for processes is shown in Fig. 2. A process, is a collection of activities that generates output (right) from its input (left). The process is controlled by its control input (top), and the activities are based on resources, methods, or mechanisms (bottom); see https://www.idef.com/ .
Fig. 1 IDEF0 product life cycle process model. The viewpoint of this model is the data that needs to be generated during design.#
The life cycle processes shown in Fig. 1 are:
Marketing
Design
Manufacturing/test/packaging
Sales and distribution
Installation service and maintenance
Use
Collection and demolishment
The viewpoint of the model from Fig. 1 is the data to be generated during the design process. The figure clearly shows that during the design process, data is generated for almost all other life cycle processes. Therefore, the stakeholders of almost all life cycle processes contribute to the product requirements in one way or another.
Fortunately, many of their requirements are covered by regulations and standards. Standardization of components, materials, production methods, and many other aspects enable a short time-to-market and facilitate global mass production.
Hierarchically organized design processes#
In general, engineers solve complex problems by breaking them down into less complex. In this way, they create a hierarchical structure in which the level of detailing increases at each level of hierarchy. This process ends when all product parts can be purchased or manufactured. Hence, designing is a top-down, hierarchically structured process.
The materialization of the design, however, proceeds bottom-up. Hierarchical levels in this phase correspond with those in the design phase. This way of working makes it possible to perform predefined integration tests of physical (sub)systems at each hierarchical level.
A design process with an identical structure at each hierarchical level facilitates the management of design projects. In section Basic design process we will present such a design process.
Risk management#
We have seen that the design of a product is a top-down process, while its materialization is a bottom-up process. As a result, the feasibility of a product is proven only when all components and parts can be purchased or manufactured. Therefore, potential design risks may not manifest themselves until the end of the design process. This, of course, is unacceptable because it causes loops in the design process.
There are several ways to avoid design loops resulting from unforeseen risks:
Keep the innovation level low:
Separate research from development
Avoid diversification
Identify and justify assumptions
Start design projects with a risk analysis
Solve design risks at the hierarchical level of their appearance.
From the above, it is clear that product development can be regarded as risk management. Risks, with the greatest product of their assumed probability of occurrence and their assumed impact, should always be addressed first.
From a risk management point of view, one should not start a design detailing familiar parts of the product. Design risks that will manifest themselves later while designing the unfamiliar parts may force the designer to reconsider the entire structure of the product. As a result, requirements of these previously detailed parts may change drastically, or worse, these parts may no longer be required.
Show stoppers#
In this book, we will pay attention to the early identification of show stoppers.
Definition
A show stopper is something that stops or could stop the progress of the design process, such as a performance-cost ratio that cannot be achieved.
Experienced designers are often intuitively aware of the consequences of economic and technological constraints on the design. Therefore they usually intuitively account for them at an early stage of the design process. A novice designer, who is not yet fully aware of the impact of such limitations, may encounter a show stopper for a design proposal at a later stage and may then be forced to reconsider the earlier selection of this proposal.
In general, design risks increase with increasing levels of innovation. Conducting research is the way to reduce those risks.
Figure Of Merit (FOM)#
Throughout the design process, designers need to select the most promising solution from a set of possible solutions. Such selections are generally based on the performance-cost ratio of the different solutions. A Figure Of Merit (FOM) is the most compact way to represent the performance-cost ratio. It is the ratio of the weighted product of the performance parameters and the weighted product of the cost factors of a solution:
Basic design process#
In this section, we will introduce a basic design process to be used at any hierarchical level. The underlying idea is to consider the product itself, as well as all of its parts, as objects. These objects or combinations thereof perform functions in a physical environment and at the expense of resources, such as matter, energy, time, and space.
This basic design process is depicted in Fig. 3. It consists of a series of activities that together define a composition of objects that fulfills the requirements of the main object. The output at the lowest hierarchical level is purchase or production data for the object. At higher levels, the outputs are initial object performance requirement specifications of subsystems. These initial specifications are the inputs at the next hierarchical level. The input at the highest hierarchical level, is the initial specification of the product.
Fig. 3 This Functional Flow Block Diagram shows the basic object design process applied at any hierarchical level of the design process.#
The different activities of this basic design process are elucidated below.
Object Performance Specification (OPS) and Object Test Specification (OTS)#
The first activity in the basic design process is the translation of the incoming initial specification into an Object Performance Specification (OPS) and an Object Test Specification (OTS). The OPS contains a variety of requirements and conditions arising from life cycle processes. The OTS specifies the test methods for these requirements. Below is a list of topics that are included in the OPS.
Functional requirements
Specification of the functions that have to be performed by the object.
Reliability requirements
Specification of the required reliability level of the performance. This is usually expressed in parameters, such as MTTF: mean time to failure, MTTR: mean time to repair, MTBF: mean time between failures, etc.
Failure Mode Effect Analysis (see: [8]) can be used to specify the probability of occurrence, the detectability, and the action to be taken at specific failure modes.
Reliability requirements can be accounted for in the FOM by defining them as performance parameters.
Safety requirements
Specification of the required safety level of the performance. This is usually done by referring to applicable safety standards.
Like reliability requirements, safety requirements can be accounted for in the FOM by defining them as performance parameters.
Performance requirements
Specification of the required quality level of the performance. This is done by defining the desired values of performance parameters.
Fig. 4 Example of a structure of an object performance specification of a Printed Circuit Board Assembly (PCA).#
Environmental conditions
Specification of operating conditions. These are the conditions under which the object must perform its function with the specified quality, safety, and reliability.
If relevant, environmental conditions during other life cycle processes, such as storage and transport should also be specified.
Resources
Specification of resources (also called cost factors) that are needed or available during the different life cycle processes. Operational resources are those necessary for the operation of the product. Examples are matter, time, and space.
Sometimes, the means or the lack of means during other life-cycle processes also must be specified.
Interaction with the environment
Every physical product influences its environment. Examples of such influences are temperature rise and pollution. Allowed and forbidden influences have to be specified.
Interfacing with the environment
Specification of interfaces with other products and operators, such as mechanical interfaces, electrical interfaces, and user interfaces.
The collective noun for all measurable quantities from 2-8 is: engineering characteristics (see Fig. 3).
Generation of functional decompositions#
As stated before, engineers solve complex problems by breaking them down into less complex. This way of working results in the presented hierarchical design method. Functional decomposition is a collective term for techniques that create a set of sub-functions that together perform the complete functionality of an object. Functional decomposition techniques are numerous. Brainstorming sessions, literature study, patent study, or techniques, such as Objectives Tree Analysis as described by Cross [9], can all be used for this purpose.
Generation of physical compositions#
The functions defined during functional decomposition must be performed by physical objects. The first step is to find a physical mechanism or operating principle to perform the function. This mechanism must then be embodied in a physical system that consists of objects realized in some technology and supplied with energy.
Performance analysis and selection#
To determine the FOM of the different solutions, the designer must analyze their performance parameters and cost factors. Such analyses can be carried out through modeling and computer-aided symbolic and/or numerical analysis. If necessary, these analyses can be supported by testing and measuring the performance and costs of so-called functional models. A functional model, or Fumo for short, is a physical model of an object that contains only the parts needed to determine specific performance aspects or cost factors. In this way, a Fumo differs from a prototype, which is a fully manufactured object that is used for the evaluation of performance and cost.
After the designer has a complete picture of the performance and the costs of all design proposals, the most promising one
is selected for further engineering.
Object Design Specification (ODS) and Object Test Results (OTS)#
The Object Design Specification is a report that summarizes the object’s design process. It discusses the functional decomposition, possible physical implementations, the performance and cost analysis, the figure of merit, and the considerations regarding the selection of the design proposal.
The Object Test Results gives the results of the tests defined in the Object Test Specification.
Design data and documents#
Throughout the design process, all kinds of data are generated. Examples are:
Calculations
Simulation models
Technical drawings and schematics
Purchase data
Production data
etc.
Parts of this data often need to be included or elucidated in documents, such as the Object Performance Specification and the Object Design Specification. Documents can be considered a specific view on the design data at some moment. These documents are intended for project management, and for securing the acquired knowledge.