System engineering techniques can be applied in product development to improve the design cycle time and reduce risks during end customer development and integration. This application requires understanding complex end customer needs at the system level and then translating them into product requirements and system architecture.
This article describes system engineering that make use of form factor reference designs unique to the automotive industry, with real case examples including design and validation aspects. The automotive industry has unique aspects which add complexity and risk to product development and integration. For example, very long qualification cycles and stringent regulatory requirements. This complexity requires tighter risk management to prevent late findings and subsequent late product launches.
System Engineering (SE) is a multi‐functional approach to engineering development with a strong focus on the holistic “big picture” of how the entire end product is brought together, deployed and supported. System engineering has been utilized and developed in various industries for many years and grown into its own specialization within the engineering field. In the past, SE has been adopted only on large scale complex programs with multiple functional domains and multiple suppliers. An extreme example of a program of this magnitude is the International Space Station developed over time with NASA and other national space agencies. This system has multiple modules each with its own mechanical, aeronautical, electrical, thermal, structural, propulsion, and other systems that all must interact successfully.
Click on image to enlarge.
Figure 1: International Space Station (ISS) Schematic (NASA, 1997) and Actual Photo (NASA, 2011)
Within the embedded community, products are typically considered as self‐contained systems. However, modern embedded systems are often part of a larger system which must be considered in the design. Figure 2 illustrates the relationship of various subsystems in a typical embedded design. Additionally, market forces demand faster‐time to‐market and more efficient development processes. System engineering offers tools to carefully define subsystems, interfaces and overall integration.
Embedded systems are now reaching the complexity of larger systems. It is typical to have multiple boards, FPGAs, operating systems (OS) or other subsystems that are integrated into embedded products. System engineering can minimize the amount ambiguity in the design phase and minimize the need for rework and redesign in the integration phases. This may reduce the need for painful escalations and “lines‐down” product support during integration. Taking your customer’s perspective on the system is an important step to understanding how SE can be applied to your product development.
Waterfall design methods
Traditional design typically uses the waterfall method. Generally this is a serial process that starts with a set of governing product requirements. These overarching requirements may come from many sources: competitive benchmarks, previous generation products, market studies or other sources. These requirements are used to develop a system architecture which drives development of subsystems. Often these subsystems are developed independently. Interfaces and subsystem boundaries where subsystems interact are typically defined in the architecture specification (ie. hardware register definitions and software APIs). Once the subsystem design is completed, they are integrated into the larger system. There are debug and redesign cycles of varying magnitude until the final product is verified and ready for delivery. Figure 3 shows a typical design cycle using the waterfall method. The debug and redesign cycles may have multiple iterations based on the stability of the system architecture and the design quality.
While this development method has worked in the past, there are several inherent limitations. One of the largest limitations is the excessive debug iterations required for system verification. Debug cycles related to subsystem interaction can extend development times and push out schedules. Additionally, requirements may not consider the full scope of verification leading to late debug. Often the first time many of the subsystems are tested concurrently is in the final integration step‐‐shortly before manufacturing or shipment to the customer. This leaves little time to work through the issues. The worst case is if there are issues uncovered by the customer resulting in a stop in production or even product recalls.
Another limitation is the assumption that the requirements can be completely known and frozen early in the program. Often times, customers or end users will use products in ways you had not considered. This can become evident after begin their product integration. When a customer puts the product in an unexpected usage, it may not perform as they expect. Both of these cases increase the risk that the customer will be dissatisfied with the product even if it meets the specification that you initially established.
As stated previously, system engineering uses a multi‐functional and holistic approach to solve the problem your product is trying to solve. (Chestnut, 1965) System engineering rigorously focuses on the following steps:
- Crisp product usage definition
- Rigorous requirements analysis
- System architecture and subsystem definition
- Incorporating cross‐functional and stakeholder feedback throughout the process
The “V‐Model” is a traditional way to visualize the system engineering process. Figure 4 shows the model discussed throughout the rest of the paper.
Define product usage
The first task is to define the system boundaries. How your product fits into the large system or customer usage. For example, the scope of the “system” will be different between a modern smartphone compared to an infotainment system in an automobile. As you begin the scoping development, it’s important that people in different aspects of the overall system interact and understand the boundaries. Once these boundaries are established, you can start defining the product usage for the system. At this point it’s important not to focus on implementation. This is critical, so you focus on understanding the problem statement without jumping to implementation details. This usage definition should be drawn from your company’s business strategy and market intelligence as well as any feedback from customers on previous generation products.
The product usage definitions are captured as a series of use case models, these are typically implementation independent. This will help drive a set of product requirements that do not force or specify a particular architecture or implementation. It is worthwhile to discuss the usage models verses the use cases. A use model covers the overall system. The use cases detail the way the system interacts with its users or with other subsystems in the system. The use conditions detail what the environment is for the product or system within the various use cases. Mapping across all three will help drive more complete requirements.
When you have a good model of the customer’s end system and usage, the inputs and outputs of the elements within your realm, and the usage models, you can more accurately engineer a potential solution. The notation of potential solution is intended to highlight that the system engineering flow expects numerous checks with the customer to make sure that the solution being proposed meets or exceeds the customer needs. It’s at these customer interactions that use cases are confirmed and revised, and changes can be incorporated. At this stage, customer feedback and iterating your use models to converge on an ideal solution is highly valuable.
Product requirement analysis
Product requirements definition and analysis is an important step during the planning phases (INCOSE, 2011). This must be done with a minimal amount of architecture definition in the requirements. Each of the requirements must tie back to the usage model to insure the correct design. Additionally, it is important to document use conditions at this stage. The use conditions may reveal additional requirements not clearly evident in the initial stages of requirements elicitation and analysis.
Figure 6 shows an example process of how the use case, environment and non‐functional requirements are captured and will drive the system architecture. At this point, it is important to engage all of the stake holders, including the end customer to verify the requirements and their intent. It is critical to make sure these requirements are captured in a form that they can be tested and verified later in the integration process.
System architecture and subsystem definition
Knowing the usagemodels and requirements will help drive system architecture andsubsystem definition best suited for the needs of the end customers. Thesystem architecture is typically an interactive process. Figure 7 showsa typical process for system architectural definition. Separating thelogical solution from the physical solution will help to generateadditional alternative solutions for the system architecture. (IEEE,2005) The logical solution focuses on how to various ways meet theproduct requirements without focusing on the technology andimplementation details. The physical solution will then developtechnology specific details to the solution. The iteration will beginwhen the technology constraints and feasibility bounds the physicalsolution. A particular technology may not be ready to use within thetime frame for the product requirements. Alternatively, it may not fitwithin the size, cost or power limits of the product.
Oncethe logical a physical architecture is complete for the system, thedetails of the subsystems can be defined. These definitions are criticalfor the subsystem design and later integration. This definitionincludes the interaction between the subsystems. Interfaces such as:
- FPGA registers for the firmware developers,
- physical location of the mounting holes for the board and chassis designer,
- firmware API’s for the driver developers or
- location of thermal solutions within the chassis for the board designers
Thesubsystem test and performance parameters will also be an output ofthis phase of the process. Each subsystem should have test cases andperformance indicators with map not only into the subsystem interaction,but also into the larger system performance for the use cases. Each ofthese should be reviewed and tracked throughout the design andintegration phases. Figure 8 shows the reviews and feedbackpoints that will be defined throughout the design process. The teams andproduct development will dictate the correct frequency and timing ofthese reviews.
Team interaction and stakeholder feedback
Atall phases, apply the use models, cases, and environments to guide alldisciplines and understand the interdependencies as solutions aredeveloped. Having the different engineering disciplines work through thedetails of the overall solution and product development collaborativelywill help keep the system perspective. Feedback throughout the processincluding cross‐functional and with customers is critical. As solutionelements get defined, also factor in how the capabilities within themget verified. Understanding the testing of capabilities and performancecan also factor into the way the solution is designed. This will improvenot only the satisfaction of the customer, but also improve the abilityto manufacture and test the product, which can translate to profit.
Example: simplifying solutions
Systemengineering in the automotive space can be uniquely challenging withthe variety of automakers around the world, value to high‐end cars,temperature extremes, shock, vibration, etc. In designing anIn–Vehicle‐Infotainment (IVI) product, the system engineer is faced withdesigning a platform to best meet a diverse set of customers with nosingle solution for I/O and functionality. As an example, Table 1 below lists four different customers and several of their requirements for their infotainment system.
Tosolve this range of differences for platform requirements, the systemengineer went to a modular approach. A single Compute Module design canbe used with various I/O baseboards. With this methodology, the systemengineer concentrates on the value add he can provide to variousplatforms. Since the majority of the design complexity is on the ComputeModule (CPU, memory, power delivery, etc.), this is the area the SystemEngineer should focus on. Besides the design complexity, the SystemEngineer must take into account other design challenges for the ComputeModule such as form, fit, function, cost, features, and flexibility tofit into different carrier boards.
Understanding the end usage,the System Engineer recognizes the I/O diversity that could be on thebaseboard. The scatter chart (Figure 10 ) demonstrates how thecompute module and base board requirements are segmented. In this case,the compute module can be sold to a diverse set of customers.
Sincewe do not enforce a particular I/O solution in the compute module, eachcustomer can differentiate themselves with the I/O strategy and featureset. Additionally, the base board will have reduced complexity. Thiswill allow you customers to create a design faster and let them focus ontheir market differentiation.
The modular approach (Figure 11 )also allows for customers to upgrade the compute complex to enable newsoftware capability without redesigning and qualifying the entiresystem. This allows the Customer to focus on their key differentiatingfeatures with minimal concern for the complex details of computecomplex.
Example: capturing adjacent requirements
Anexample of System Engineering bringing benefit to a project was a casewhere a hardware team defined a new module connector pin out. Theprevious generation of working product was used as a starting point. Thenew capabilities and upgraded power capacity was factored into a newpin out and an initial revision of the connector definition wasapproved. A sub‐team review with a firmware engineer highlighted adefect in the hardware team’s requirements. One new use case for thefirmware was to add hardwired monitoring of the baseboard. This wouldrequire a new signal on the connector and routing in the module design.Further discussion in this review also highlighted that this new signalwould need to be conditioned and latched by hardware on the module. Thefirmware would then use a new signal connection on the module to clearthe latch. This dialog changed not only the connector definition, butalso circuits on the module. Finding this issue before the design wascompleted and prototyped saved time and money for the program.
Expanding collaboration to all your users can save time and money by finding issues before real products are produced.
Example: system architecture for EMI
Intraditional development approach, EMI experts’ primary interaction islimited to the hardware designers, with the goal of optimizing thelayout and adding EMI filters in the design. However greater benefitsand an efficient design can result when the EMI experts interact outsidethis boundary. For example, the EMI team engaged with MechanicalEngineering and the rest of the system engineering team, quite early inthe design. This allowed the EMI engineer to proactively present thegoals, design challenges and deliver training. With this, reaching EMIcompliance for the system has become a shared responsibility. TheMechanical Engineer has now enough knowledge to work with the EMIengineering to optimize the chassis design, to address the source of theEMI problem. A hardware engineer now jointly appreciates and works withthe software engineer in defining the connector pin out that willresult in low radiation and minimize signal integrity problems.
Thesystem engineering and “V‐model” approach provides techniques tominimize the limitations of the traditional waterfall model. SystemEngineering applies engineering effort in the early phases of design andplanning to develop an overall technical plan for the productdevelopment. There is an effort to create a complete picture of the enduser usage. Looking into the environment of how your products are usedwill help build the model of what types of systems you need to beconcerned about. This model also focuses on a high level ofcross‐functional communication. This interaction and communicationallows ideas to flow freely between development teams. Finally, there iseffort put into integrating the product at each phase. This is not justduring development—it includes the definition and planning phase.
Systemengineering practices have shown value in the embedded design space.Its practice can bring technical and business value to most products. Itinsures the development teams are focused on solving the right customerproblems and meeting the real customer requirements. It has been shownto improve the efficiency of cross‐functional development teams byincreasing communication and reducing the integration time required. Insome cases, a modular design provides the benefit of being easilyintegrated into the customer products.
Chestnut,H. (1965). Systems Engineering Tools. Hoboken, NJ: John Wiley and Sons.IEEE. (2005). IEEE STD 1220‐2005. New York, NY: IEEE Publications.
INCOSE. (2011). Systems Engineering Handbook. San Diego, CA: INCOSE.
NASA. (1997, March 27). NASA. Retrieved April 03, 2013, from www.nasa.gov: http://www.nasa.gov/pdf/116060main_model12.pdf
NASA.(2011, March 7). NASA. Retrieved April 3, 2013, from nasa.gov:http://spaceflight.nasa.gov/gallery/images/station/assembly/lores/s133e010447.jpg
This article was presented as part of a class (ESC-326) taught by the authors at the Embedded Systems Conference 2011.
Matthew Torgerson is a Design Manager in the Intelligent Systems Groups at Intel. He hasover 15 years of experience developing hardware for consumer,semiconductor, enterprise and datacenter industries He is currentlyinvolved with developing solutions for Intel’s Intelligent Systemscustomers.
Paul Durazo is a System Integration Engineer inthe Intelligent Systems Group at Intel working on platform use casesand system integration. Paul has 27 years’ experience at Intel invarious technical positions and is currently supporting the AutomotiveSolutions Division.
Todd Langley is a Hardware Engineer inthe Intelligent Systems Group at Intel with 28 years of experience inhardware and system design. He has spent the past 14 years at Intelarchitecting and designing reference and validation designs for embeddedproducts.
Vira Ragavassamy is a Principal Engineer in theIntelligent Systems Group at Intel with 18 years of experience in theAnalog and RF system design. He has spent the past 9 years at Intelsolving signal integrity and power integrity problems in embeddedproducts.