MPD 575 Design for (Embedded Systems) Integration

1. MPD 575Design for (Embedded Systems) Integration Kyle Post George Walley

2. An Integration Analogy  Missing or overlooked pieces Incorrect interfaces  MPD575 Weaver

3. …but when done well… MPD575 Weaver

4. Development History December 2008 – Initially developed by K.Post & G.Walley (Cohort 9) Hopefully not headed here MPD575 Weaver

5. Design for (Embedded Systems) Integration • Introduction • Motivations for DfI • Key Points & Principles • Processes & Tools • Heuristics • Examples • Summary • References MPD575 Weaver

6. Introduction • Introduction • Scope • Definitions • Relation to other disciplines • Stakeholders • Characteristics • Motivations for DfI • Key Points & Principles • Processes & Tools • Heuristics • Examples • Summary • References MPD575 Weaver

7. Scope Design for (Embedded Systems) Integration, or DfI, is about how to overcome the challenges of integrating complex electronic systems or larger systems that include them, to reduce costs and the time it takes to assemble, test, and tune a product.By way of pushing these development considerations earlier in the design process, DfI may also significantly reduce development time. However, until such process changes are accepted and personnel are trained, development time may increase. It is worth noting that much of the material covered is naturally also applicable to systems that do not contain embedded electronic elements. Exhaust Gas Oxygen Sensor Electronic Control Module References: http://www.auto-diagnostics.info/images/ford_eec_iv.jpg http://www.imagecows.com/uploads/_71ec-ford-engine.jpg Internal Combustion Engine http://fordfuelinjection.com/images/hego.jpg MPD575 Weaver

8. Mission Statement Product Planning Concept Development System-Level Design Detail Design Testing and Refinement Production Ramp-Up Product Launch Scope Product development steps largely influenced by DfI Reference: Product Design and Development. Ulrich & Eppinger. 2004 MPD575 Weaver

9. Definitions System Engineering: A systematic, disciplined approach to define, cascade, link, and manage stakeholder-driven requirements, functions and interfaces, and to satisfy those with the development of functionally driven, synergistic, innovative alternatives. Visteon 1999 MPD575 Weaver

10. Definitions Systems Integration: The progressive physical linking together of the parts of a system or component. Hatley, Derek. Process for System Architecture & Requirements Engineering. p410 The merger or combining of two or more components or configuration items into a higher level system element, and ensuring that the logical and physical interfaces are satisfied and the integrated system satisfies its intended purpose. Kossiakoff, Alexander. Systems Engineering, Principles and Practice. P449 System integration is the bringing together of components into one system and ensuring that the subsystems function together as a system. possible because of interactions between subsystems. Wikipedia (http://en.wikipedia.org/wiki/System_integration) MPD575 Weaver

11. Definitions Embedded Systems: A special-purpose computer system designed to perform one or a few dedicated functions, often with real-time computing constraints and embedded as part of a complete device including hardware and mechanical parts.Since the embedded system is dedicated to specific tasks, design engineers can optimize it, reducing the size and cost of the product, or increasing the reliability and performance. Some embedded systems are mass-produced, benefiting from economies of scale. Wikipedia (http://en.wikipedia.org/wiki/Embedded_system) A system that is installed within a larger system and which, from the user’s or operator’s point of view, is part of the larger system. Hatley, Derek. Process for System Architecture & Requirements Engineering. P408 Real-Time Systems: Hardware and software systems that are subject to … operational deadlines from event to system response. Wikipedia (http://en.wikipedia.org/wiki/Embedded_system) As fast as required. A real-time system must respond to a signal, event or request fast enough to satisfy some requirement. Real time often refers to process control and embedded systems. PC Magazine Online (http://www.pcmag.com/encyclopedia_term/0%2C2542%2Ct%3Dreal+time&i%3D50259%2C00.asp) MPD575 Weaver

12. Relation to Other Disciplines DfI comes at the intersection of many other DfX disciplines and, luckily for the diligent engineer, equally benefits from many of the practices already in-place for these other disciplines, and vice-versa. • DF Assembly • DF Commonality • DF Export • DF Geometric Compatibility • DF Globalization • DF Modularity • DF Package • DF Reuse • DF Robustness • DF Reliability • DF Quality • DF Serviceability • DF Testability MPD575 Weaver

13. Stakeholders • Primary Stakeholders: • System Owner • System Architects/Engineers • Hardware and/or Software Integrators • Secondary Stakeholders: • Test Engineers • Component & Subsystem Engineers • Finance & Purchasing Controllers • Business & Project Leaders • Other Stakeholders: • Customer • Customer Service / Parts & Repair • Company stakeholders MPD575 Weaver

14. Motivations for DfI • Introduction • Motivations for DfI • Unique Challenges to Embedded Systems • Proliferation of Embedded Systems • Increasing Complexity of Electronic Systems • Standards & Regulations • Globalization & In/Out-Sourcing • Pressure to Reduce Development Time • Pressure to Reduce Costs • Insurance Against Loss of People-Assets • Marketability of Products • Varying Operating Environments • Key Points & Principles • Processes & Tools • Heuristics • Examples • Summary • References MPD575 Weaver

15. Motivations for DfI Unique Challenges to Embedded Systems • Engineering Domains • Coordinating information and elements across several domains(typically need competency across domains - mechanical, electrical, software, etc…) • Physical Aspects • Characterizing the system’s hardware in the software(developing & translating accurate system transfer functions into embedded controls) • Trading-off adjusting system functionality through software or hardware(changing software is often easier/cheaper but not always, or not always the best way) • Actively adapting for changes to physical characteristics of the system(maintaining performance during break-in, wear, environmental conditions, abnormal use) • Timing Aspects • Interactions occurring on the order of milliseconds or faster(how to integrate and troubleshoot things you can’t see) • Coordinating events and communication(e.g. engine spark/air/fuel, automated manufacturing & assembly, TCP/IP) • Complexity Aspects • The same flexibility embedded systems afford also adds complexity(infinitely adjustable/tunable, but finite time to actual calibrate) • Managing this complexity while hiding it from end users(e.g. plug-and-play computer devices) MPD575 Weaver

16. Motivations for DfI Proliferation of Embedded Systems • “Consumer products” and “consumer electronic devices” are almost synonymous these days, with even toasters and egg timers containing ‘smart’ embedded systems, both for safety and added functionality. • In the automotive domain, the industry has watched electronic content (software and the controllers in which they reside) increase dramatically (100+) over the past three decades. At the beginning, separated or “silo” architectures were common, requiring little interaction between electronic systems due to the complexities involved and not yet well-established interfacing standards. • Now with the experience and expertise gained over this period and increasing pressure to reduce piece costs, the industry is seeing 60-80 controller modules on average at the top end in many vehicles, with the average between 35-40, and targets to reduce this much further. MPD575 Weaver

17. Motivations for DfI Increasing Complexity of Electronic Systems • The increasing consumer demand and regulations for safety, fuel efficiency, and emissions keep pushing the complexity of tomorrows automobiles. This has materialized into multiple embedded controllers managing the engine system, brake system, air bag system, and others. The communication architecture between these is essential for the integration of the system. As complexity increases, the principles of DfI become increasingly more important. MPD575 Weaver

18. Motivations for DfI Increasing Globalization • Many companies are expanding beyond original borders, whether just locally or to outside counties, states, and even countries. • Debates on out-sourcing or in-sourcing of systems, parts, and services have increased as companies compete people/knowledge/time costs. • In both of these cases, the increased distances between interfacing groups and differences in time-zones, languages, and cultures present unique challenges to successful integration efforts along the way. MPD575 Weaver

19. Motivations for DfI Pressure to Reduce Development Time • Reducing the development time reduces the time to market of products which is important in competitive markets. DfI reduces development time by enabling the system to be integrated successfully the first time instead of the find and fix approach to integration. MPD575 Weaver

20. Motivations for DfI Pressure to Reduce Costs • Customers are only willing to pay for value-add operations. Troubleshooting interfaces is not value-add to the product and should be avoided. • When the designing of each component is done in a vacuum the integration will not likely be successful the first time through, simply due to mismatched poor interfaces. This then turns into a find and fix approach. This fix increases cost as interfaces are redesigned causing incremental costs that would not be needed if the interfaces were setup correctly in the initial design. MPD575 Weaver

21. Motivations for DfI Standards & Regulations • Industry standard hardware and software interfaces, connectors, and pin-outs used by suppliers and competitors • PC expansion card interfaces in computers • Common voltage/power ratings on devices (i.e. 3.3v, 5v, 9v, 12v) • Ex: Suppliers developing components to AUTOSAR specs • Commodity prices and sourcing for common components • FAA, FCC, NHTSA, EPA, CARB, etc… regulations for monitoring, controlling, reporting … MPD575 Weaver

22. Motivations for DfI Insurance Against Loss of People-Assets • With well-documented interfaces and standards for defining and integrating systems, events like losing a knowledgeable/experienced employee will not carry the same risk or negative impact. • A well-established and documented process for architecting and engineering systems, and for defining their interfaces, will provide easier training for new employees MPD575 Weaver

23. Motivations for DfI Marketability of Products • The cost and time of integrating a standards-compliant component can be much reduced over a proprietary one, and it also allows easier dual- or multi-sourcing of a component or system • If OEM A decides to support and buy only AUTOSAR-compliant seat controller modules…then suppliers who also support this interface/architecture are more marketable to OEM A. MPD575 Weaver

24. Motivations for DfI Varying Operating Environments • Products need advance planning to properly support the unique procedures, monitoring & adjustment tools, and environmental conditions during testing and prove-out phases – including desktop simulations, Software-in-the-Loop (SIL), Model-in-the-Loop (MIL), Hardware-in-the-Loop (HIL), and prototype vehicle testing. • Designing these into the product later can disrupt the balance of the system’s design and/or require large amounts of time. MPD575 Weaver

25. Key Points & Principles • Introduction • Motivations for DfI • Key Points & Principles • Design for Integration View of the Systems Engineering V • Project Planning for Integration Activities • Architecture Considerations • Simulation & Testing Considerations • Hardware Considerations • Software Considerations • Processes & Tools • Heuristics • Examples • Summary • References MPD575 Weaver

26. Key Points & Principles Design for Integration View of the Systems V Integration Validation Architecture - Modular or Integrated Integration / Test Plan Architecture - Partitioning Integration / Test Plan Integration Verification Interface Definitions / Requirements Integration / Test Plan Integration Verification Integration Verification Interface Negotiation across Boundaries Integration / Test Plan Detailed Design MPD575 Weaver

27. Key Points & Principles Design for Integration View of the Systems V Generic basics from the INCOSE Systems Engineering Handbook v3… 4.6 Integration Process 4.6.1 Purpose The purpose of the Integration Process is to realize the system-of-interest by progressively combining system elements in accordance with the architectural design requirements and the integration strategy. This process is successively repeated in combination with the Verification and Validation Processes as appropriate. 4.6.2. Description The Integration Process includes activities to acquire or design and build enabling systems needed to support the integration of system elements and demonstration of end-to-end operation. This process confirms all boundaries between system elements have been correctly identified and described, including physical, logical, and human-system interfaces; and confirms that all functional, performance, and design requirements and constraints are satisfied. Interim assembly configurations are tested to assure correct flow of information and data across interfaces to reduce risk, and minimize errors and time spent isolating and correcting them. Figure 4-6 is the context diagram for the Integration Process. SEHandbookV3.pdf pg 4.11 MPD575 Weaver

28. Key Points & Principles Design for Integration View of the Systems V SEHandbookV3.pdf pg 4.11 MPD575 Weaver

29. Key Points & Principles Design for Integration View of the Systems V 4.6.5 Process Activities: Activities in the Integration Process include: • Schedule Integration Testing Tools and Facilities • Assemble system elements according to the integration plan • Validate Interfaces – confirm correct flow of information across internal interfaces through “black box testing” at each successive level of assembly • Test and analyze Assemblies – confirm correct functionality of assembled products through integration testing and analysis at each successive level of assembly • Document integration testing and analysis results • Document and control the architectural baseline – this includes capturing any modifications required during this process Common approaches and tips: • Keep the Integrated Product Team engaged to assist with configuration issues and redesign. • Maintain configuration control over including drawings, specifications, interface control drawings, and published analyses. • Define an integration strategy that accounts for the schedule of availability of system elements, including human operators, and is consistent with fault isolation and diagnosis engineering practices. SEHandbookV3.pdf pg 4.11 MPD575 Weaver

30. Key Points & Principles Project Planning for Integration Activities To best support the early integration activities just shown, as well as the traditional right-hand-side activities, project objectives, responsibilities, and resource planning play critical roles to enabling successful integration. • Product Life Cycle • Component & Platform Commonization • Resources • Time • Personnel • Capital • Organizational & Process Considerations • Reporting Structure • Globally Dispersed Teams vs. Localized Teams • Reward Systems MPD575 Weaver

31. Key Points & Principles Project Planning for Integration Activities Product Life Cycle Like any other whole product or sub-system/sub-component, the expected duration and timed progression through an embedded system’s life cycle should be considered early to avoid under- or over-building. With the rapid changes in electronic hardware and software systems of today, this become all the more important. Example automotive architecture where all of the subcomponents shown are specifically built for the core vehicle ‘platform’ at the center MPD575 Weaver

32. Key Points & Principles Project Planning for Integration Activities Resources Capital is very closely tied to time and personnel. The ideal situation is to design the system so that integration happens once while minimizing the resources needed to achieve system requirements. When working with outside organizations, defining the integration boundaries and testing time involved depends on what level of decomposition the system is split between organizations. When moving down the branches of decomposition the more system integration time (requirements negotiation, integration planning, integration testing) is needed. The increase in boundaries is exponential while moving down the decomposition. MPD575 Weaver

33. Key Points & Principles Project Planning for Integration Activities Organizational/Globalization Considerations Reporting Structure How an organization is organized will determine what objectives and priorities various engineering roles will have. For example, an organization that has several dozen integrators and testers, but only a handful of engineers, communicates that the primary objective is to get product into integrators’ and testers’ hands so that gaps can be found and fixed as quickly as possible. MPD575 Weaver

34. Key Points & Principles Project Planning for Integration Activities Organizational/Globalization Considerations Globally Dispersed Teams vs. Localized Teams As companies grow to intra- & inter-city, state, national, international size, there are important workforce considerations to be made with regard to where to place, what size to make, and how to organize product development and manufacturing teams. Challenges in these situations include: • Communication is harder • Coordination and resolution of issues is harder • Often multiple languages • Multiple time-zones • Cultural differences in working norms MPD575 Weaver

35. Key Points & Principles Architecture Considerations The success of DFI is dependent on the system architecture. The architecture acts as the foundation of the system and thus cannot be ignored. A well defined architecture will lead to faster development times at lower costs. A lack of a proper architecture can lead to excess workload in the form of troubleshooting which directly relates to higher costs, longer development times, and a reduction in quality. This could lead to failure to realize the system. Successful embedded systems integration relies on the architecture of the complete system not only the software architecture (which is usually the main architecture focus for imbedded systems) • Systems Engineering & Systems Architecting Principles • Integrated vs. Modular • System Decomposition • Open vs. Closed • Interfaces MPD575 Weaver

36. A A C C B B Low Coupling High Coupling Key Points & Principles Systems Engineering & Systems Architecting Principles Reduce coupling as much as possible "The coupling between modules should be – in order of preference – data, data structure, control, common, and content." Maier, Mark. The Art of Systems Architecting. p170

37. A A Few Interfaces (fan in) Many Interfaces (fan out) Key Points & Principles Systems Engineering & Systems Architecting Principles Minimize the number of interfaces "Module fan-in should be maximixed. Module fan-out should generally not exceed 7+/-2." Pg 170 The Art of Systems Architecture” Maier, Mark. The Art of Systems Architecting. p170

38. A E W X C Y B D V Z Key Points & Principles Systems Engineering & Systems Architecting Principles Maximize internal complexity and minimize external complexity "The cohesion of the functions allocated to a particular module should be – in order of preference – functional / control, sequential, communicational, temporal, periodic, procedural, logical, and coincidental.” Maier, Mark. The Art of Systems Architecting. p170

39. Key Points & Principles Architecture Considerations System Decomposition The system should be decomposed functionally and physically to determine the best way to organize the system. Example of exponential complexity of integration while moving to lower decomposition levels (7 per level).

40. Key Points & Principles Architecture Considerations Integral vs. Modular http://www.shopping.hp.com http://www.shopping.hp.com Modular Architecture Integral Architecture • The level of modularity should be decided based on the product life cycle, level of in-house design, and percentage of parts bought. • It also influences the product integration and testing

41. Key Points & Principles Architecture Considerations Integral vs. Modular (Continued) The product life cycle must be considered when developing the architecture for embedded system integration. A modular approach is more efficient for multiple, concurrent, and/or short product life cycles which can benefit from reusing the modules. Long product cycles for functions requiring a high level of performance lend themselves to an integrated architecture.

42. Black Box A E C B D Closed Architecture Open Architecture Key Points & Principles Architecture Considerations Open vs. Closed Open architectures allow everyone to see within the boundaries of each sub-system for easy determination of how the interfaces are designed. In closed architectures the sub-systems are “black boxes” so the interface requirements must be complete and detailed since the detailed design is not shared. As you move from an open to closed architecture the need for well defined interfaces increases. A lack of very well defined interfaces, can easily lead to misunderstanding of how the interfacing system works.

43. Key Points & Principles Architecture Considerations Interfaces NumberThe number of interfaces is dependent on the type of architecture implemented, but the general want is to keep them simple and minimal. The interfaces for modular architectures must be managed more actively than for integrated architectures. Example: Ten different signals for different diagnostic or trouble messages vs. a single (well-defined, well-documented) parameter TypesThe four primary types of interfaces - Material Flow, Energy Flow, Physical Connections, Information/Control - but further helpful breakdowns often exist as well. Embedded System Specific Types of Interfaces Memory Interfaces Port Interfaces Timer Interfaces Power Electronics Interfaces Analog Interfaces Binary Interfaces (Switches and LEDs) Stepper Motor Interfaces AC / DC Motor Interfaces Stiffler, Kent. Design with Microprocessors for Mechanical Engineers

44. Key Points & Principles Architecture Considerations Hardware-Related Interfaces Where software I/O is more easily changed (relatively), the hardware I/O for an embedded system can have huge cost impacts if changes are needed, even if they are found early-on if prototype hardware has already been produced. One approach is develop a small portfolio of a range of more generic and re-programmable control systems/modules. However, even in doing this, care must be taken to properly account for the right number and types of inputs and outputs for the system. For example: PWMs, digital vs. analog inputs and outputs, low-level driver availability for reading & interpreting these on your platform, interrupt-driven lines, etc…

45. Key Points & Principles Architecture Considerations Software-Related Interfaces The Inputs and Outputs of embedded control systems are the way the software interfaces with the outside world. They are the boundary between software and hardware or other networked devices. Inputs and Outputs must be coordinated to ensure the system performance and reliability. Integrating the hardware and software requirements are essential. One effective method of capturing these requirements is within an interface contract. The interface contract captures the details of the hardware including any limitations that the software must account for so that the hardware is not damaged. An example would for an actuator would be which pins are connected to the controller, what kind of hardware filter is used, EMC requirements, current requirements, and detailed performance requirements.

46. Key Points & Principles Simulation & Testing Design Simulation & Analysis Integration Methods

47. Key Points & Principles Simulation & Testing Design Simulation & Analysis At the core of solid, upfront designing for integration and high quality products is a model-based approach. Though this is often inferred to mean the use of complex modeling & simulation software packages, the truth is that engineers use a model-based approach (mental models, drawing on-paper, etc…) regardless of the level of technology involved. Concerted effort to develop, validate, and begin using these models early in concept exploration phases can have tremendously positive effects on downstream development and integration activities. The following describes model-based engineering (MBE) in more detail. Types of MBE Benefits & Challenges of MBE Model Fidelity Requirements

48. Key Points & Principles Simulation & Testing Design Simulation & Analysis Types of MBE For non-electronic systems, engineered models can be as simple as static objects like a clay or foam model of a new cell-phone – just enough to convey the desired product attributes and get feedback, either directly in response to tests or from a sample pool of others like focus groups. For embedded systems, however, the models are typically more complex though this may only mean they are a handful of transfer function equations in a spreadsheet that update output values based on perturbed inputs. Because integration is not just something that happens at the end of development, but often many times through-out, building-in model architectures and interfaces that speed integration tests can greatly reduce integration time, and thus improve a team’s ability to even try out more concepts using the various models available.

49. Key Points & Principles Simulation & Testing Design Simulation & Analysis Benefits & Challenges of MBE Computer-enhanced or computer-facilitated Model Based Engineering has gained considerable ground, particularly over the past decade, as improvements in computer performance and modeling software have enabled more accurate modeling of systems without the need for CRAY supercomputers – particularly those systems with complex interactions, those that naturally occur at very high-speeds, and/or are time-varying – all elements that can be difficult to capture or capture accurately in traditional models. Thus the draw to the MBE carrot is a (purported) promise of reduced development costs by allowing engineers to test out designs for performance, serviceability/assembly, and conformance to regulations (EMC, etc…) on virtual hardware, before having any actual parts manufacturing or assembled. MBE is not without its unique challenges and pitfalls however. Even with the capabilities afforded by these software packages, accurate modeling of real-world components and their operating environments often can take more time to develop and tune than would be the cost to manufacture several actual systems.

50. Key Points & Principles Simulation & Testing Design Simulation & Analysis Model Fidelity Simple, directionally-correct models: for early system feasibility and sizing More advanced models: for system interaction, timing, and performance studies Mature, validated models: for testing and refinement before hardware is ordered or arrives, OR to supplement testing resources (i.e. only so many real prototypes) There are a couple lines of thought with regard to modeling systems – We cannot model new products that contain embedded systems with enough confidence to significantly reduce physical prototypes. Simple models are helpful early on, and later models are refined based-on physical prototype performance, in order augment testing resource availability. If we can’t model it, how can we purport that our design is expected to really work?