Transcript MPD 575 Design for (Embedded Systems) Integration

MPD 575
Design for (Embedded Systems) Integration
Kyle Post
George Walley
An Integration Analogy
 Missing or overlooked pieces
Incorrect interfaces 
MPD575 Weaver
2
…but when done well…
MPD575 Weaver
3
Development History
December 2008 – Initially developed by K.Post & G.Walley (Cohort 9)
Hopefully not headed here
MPD575 Weaver
4
Design for (Embedded Systems) Integration
•
•
•
•
•
•
•
•
Introduction
Motivations for DfI
Key Points & Principles
Processes & Tools
Heuristics
Examples
Summary
References
MPD575 Weaver
5
Introduction
•
Introduction
–
–
–
–
–
•
•
•
•
•
•
•
Scope
Definitions
Relation to other disciplines
Stakeholders
Characteristics
Motivations for DfI
Key Points & Principles
Processes & Tools
Heuristics
Examples
Summary
References
MPD575 Weaver
6
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
http://fordfuelinjection.com/images/hego.jpg
MPD575 Weaver
Internal Combustion Engine
7
Scope
Product development
steps largely
influenced by DfI
Mission
Statement
Product
Planning
Concept
Development
System-Level
Design
Detail
Design
Testing and
Refinement
Production
Ramp-Up
Product
Launch
Reference: Product Design and Development. Ulrich & Eppinger. 2004
MPD575 Weaver
8
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
9
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)
Kossiakoff and
Sweet's Systems
Engineering
Phases
Needs Analysis
Stakeholder
Requirements
Requirements
Analysis
Definition
INCOSE Technical
Process
Process
Process
Concept Concept
Advanced
Exploration Definition Development
Architectural Design Process
Engineering
Design
Integration and
Evaluation
Production
Operation and support
Implementation Integration Verification Transition Validation Operation Maintenance Disposal
Process
Process
Process
Process Process Process
Process
Process
MPD575 Weaver
10
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
11
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
o DF Commonality
o DF Export
o DF Geometric Compatibility
o DF Globalization
o DF Modularity
o DF Package
o DF Reuse
o DF Robustness
o DF Reliability
o DF Quality
o DF Serviceability
o DF Testability
o
MPD575 Weaver
12
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
13
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
14
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
–
Coordinating events and communication
(how to integrate and troubleshoot things you can’t see)
(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
15
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
16
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
17
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
18
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
19
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
20
Motivations for DfI
Standards & Regulations
•
Industry standard hardware and software interfaces, connectors, and pinouts 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
21
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
22
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 dualor 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
23
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-theLoop (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
24
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
25
Key Points & Principles
Design for Integration View of the Systems V
Architecture - Modular or Integrated
Integration
Integration / Test Plan
Validation
Architecture - Partitioning
Integration
Integration / Test Plan
Verification
Interface Definitions / Requirements
Integration
Integration / Test Plan
Verification
Interface Negotiation across Boundaries
Integration
Integration / Test Plan
Verification
Detailed Design
MPD575 Weaver
26
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
27
Key Points & Principles
Design for Integration View of the Systems V
SEHandbookV3.pdf pg 4.11
MPD575 Weaver
28
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
29
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.
o
Product Life Cycle
o
o
Resources
o
o
o
o
Component & Platform Commonization
Time
Personnel
Capital
Organizational & Process Considerations
o
o
o
Reporting Structure
Globally Dispersed Teams vs. Localized Teams
Reward Systems
MPD575 Weaver
30
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
31
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
32
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
33
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
34
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)
o
o
o
o
o
Systems Engineering & Systems Architecting Principles
Integrated vs. Modular
System Decomposition
Open vs. Closed
Interfaces
MPD575 Weaver
35
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
A
A
C
C
B
B
Low Coupling
High Coupling
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
A
A
Many Interfaces (fan out)
Few Interfaces (fan in)
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
A
E
W
C
B
X
Y
D
V
Z
Key Points & Principles
Architecture Considerations
System Decomposition
The system should be decomposed functionally and physically to determine the
best way to organize the system.
Exponential Growth of System Partitions
2500
Parts
2000
Number of Partitions
•
Example of exponential
complexity of integration while
moving to lower decomposition
levels (7 per level).
1500
1000
500
0
Sub-Component
Sy stem
Sub-sy stem
C omponent
1
2
3
System Partition Level
4
5
Key Points & Principles
Architecture Considerations
Integral vs. Modular
http://www.shopping.hp.com
Modular Architecture
http://www.shopping.hp.com
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
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.
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.
A
E
Black Box
C
B
D
Open Architecture
Closed Architecture
Key Points & Principles
Architecture Considerations
Interfaces
o
Number
The 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.
o Example: Ten different signals for different diagnostic or trouble
messages vs. a single (well-defined, well-documented) parameter
o
Types
The four primary types of interfaces - Material Flow, Energy Flow, Physical
Connections, Information/Control - but further helpful breakdowns often
exist as well.
o
Embedded System Specific Types of Interfaces
o Memory Interfaces
o Port Interfaces
o Timer Interfaces
o Power Electronics Interfaces
o Analog Interfaces
o Binary Interfaces (Switches and LEDs)
o Stepper Motor Interfaces
o AC / DC Motor Interfaces
Stiffler, Kent. Design with Microprocessors for Mechanical Engineers
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 reprogrammable 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…
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.
Key Points & Principles
Simulation & Testing
• Design Simulation & Analysis
• Integration Methods
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 modelbased 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.
o
o
o
Types of MBE
Benefits & Challenges of MBE
Model Fidelity Requirements
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.
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.
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 –
1. 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.
2. If we can’t model it, how can we purport that our design is expected to really work?
Key Points & Principles
Simulation & Testing
Integration Methods
Depending on factors like the size of the project, resources available, time
deadlines, degree of reuse from past projects, and complexity/number of pieces to
integrate, teams may approach integration at different points along the continuum
from all-at-once to a piecemeal/incremental approach.
For most complex systems involving embedded systems, an all-at once approach –
particularly on new projects - introduces too much variation to make sense of all of
the integration points and adequately test all the interfaces, even though this
approach would, if fairly well designed and integrated, save on integration and
testing resources.
On the flip-side, components of embedded systems often cannot be tested in a
complete vacuum but rather require complicated testing systems to do so because
of the need for things like communication buses and series of hand-shaking or
synchronization signals to be exchanged just to a system to initialize properly.
Sometimes this is simply easier with more pieces of the system pre-integrated.
MPD575 Weaver
51
Key Points & Principles
Simulation & Testing
Integration Methods
It’s for these reasons that early architecting and design decisions can play a critical
role in defining the possible integration and testing methods later in the process.
Take for example a highly coupled & integrated (vs. modular) system design. The
tight coupling will make it difficult for subsystem/subassembly testing to be brokendown as far as for a more modularly design system, where a minimized set of
interfaces signals and other interfaces may be able to be ‘stubbed-out’.
It is also important to recall from earlier that integration is not something that only
happens on the right-hand-side of the Systems Engineering Vee, as early integration
of models (of varying fidelity) during concept exploration and selection should also
be planned-out.
MPD575 Weaver
52
Key Points & Principles
Hardware Considerations
Hardware for embedded systems includes a wide range of components and
subsystems. These range from individual circuit board components like resistors
and capacitors to entire electronic control modules complete with all accompanying
sensors, casings, and external connector harnesses.
However, many integration problems can be avoided through purposed effort and
analysis behind the following areas
Processing Capability & Memory Size
Packaging
Operating Environment
Power
MPD575 Weaver
53
Key Points & Principles
Hardware Considerations
Processing Capability & Memory Size
Like any other piece of hardware in a system, when these items are not quantified or
properly considered the solution is either expensive or a compromise on system
configurability, performance, or operating robustness & reliability.
This affects integration because the final size or processing power, if not properly
estimated, bounded, or otherwise specified, if often determined late or by default at
the time of integration – which flexibility in time and financial resources is typically
most limited.
Key Points & Principles
Hardware Considerations
Processing Capability & Memory Size
Determining and specifying the amount and type of processing power and memory
required is a function of several items including:
• Speed of the fastest process the software must execute
• Expected S/W size + growth over the project & product life cycle
– Noting this can be very different for hand- vs. autogenerated-code
•
•
•
•
•
•
•
•
•
Required read/write ability & access speed
Existing or desired programming (flashing) tools & interfaces
System volatility on power-loss
Upgradability of modules (for service or for improvements)
Power requirements
Packaging space & external connectors
Operating environment (e.g. heat, vibration, humidity robustness)
Chipset & base operating system compatibility
Cost
Key Points & Principles
Hardware Considerations
Packaging
Though mentioned previously with regard to processor and memory sizing, the overall
packaging of hardware often has a large play in the trade-off period of embedded system
design.
Ex: iPod – extremely trimmed down physically, as the cost of a better antennae, larger battery,
physical keyboard…and thus functionality was adapted and/or reduced to accommodate
higher level requirements.
Packaging also plays a key integration role in integration’s close relationship with both
serviceability and assembly. Placing connectors at particular angle may make them shed
water from the environment, for example, but in testing assembly, service, and final assembly
these physical considerations may make them much more difficult to work with. This can lead
to increased integration time, and the chance for misassembled or damaged-during-assembly
parts.
There are also other opportunities with embedded system packaging, such as using a
component’s own packaging as a heat sink or purposely locating the system close to another
system to reduce wiring, separate heating elements, power, etc…
Key Points & Principles
Hardware Considerations
Power
Power requirements for products with embedded systems are another critical area
for taking a system-wide approach to requirements capture, analysis, and trade-off.
Highly complex embedded systems can have a seemingly limitless number of
combinations of devices active, all using varying levels of power at the same or
different times than other devices. Simply adding up and over-specifying the system
to support the ‘worst case’ scenario – however unlikely or even impossible - may
sound convenient and straight-forward, but is rarely a viable option for reasons of
cost alone.
Key Points & Principles
Software Considerations
Software for embedded systems control various functions. This includes the Real
Time Operating System (RTOS), hardware drivers, and application code. The
software not only has to interface with the system it is controlling but also the
computer hardware it resides in. The computer memory, processing speed, and
hardware layout all must be considered.
•
•
•
•
Memory Footprint & Allocation
Chronometrics / Processing Requirements
Physical Partitioning to Available Hardware
Calibration & Tunable Parameters/"Hooks"
MPD575 Weaver
58
Key Points & Principles
Software Considerations
Memory Footprint & Allocation
Random Access Memory (RAM) & Read Only Memory (ROM)
The memory allocation is an important and difficult aspect of embedded controls.
The amount of software needed to perform a function varies by the design, style,
and compiler used to create the imbedded software. The exact size of the memory
needed for the system with various sources of code varies greatly. This does not
mean it should not be done though. Specifying more than is needed raises the piece
price of the system. Not enough memory and the system will not function. This ends
up costing even more to add more memory later, optimize the code for memory. Not
to mention the time lost to implement these.
Key Points & Principles
Software Considerations
Memory Footprint & Allocation
•
•
•
•
•
DFI will only be successful if the software fits in the embedded controller.
The memory should be allocated for each software architecture chunk.
Memory size requirements need to be identified in the requirements.
The requirements need to be tracked to ensure the ability to integrate the total
application into the processor. This information should be tracked so as future
programs are developed the memory estimates will become more accurate.
The optimization of memory size can come as a cost to system upgrades. An
optimal memory system would have exactly the amount of memory needed to
complete the system function. New requirements to the system would require
upgraded hardware to handle the new amount of memory needed for the
additional software. Future expansions should be considered when specifying
the memory to include planned and unplanned software expansions. As
memory prices decrease the tradeoff for optimizing memory space becomes
less important.
Key Points & Principles
Software Considerations
Chronometrics / Processing Requirements
•
•
•
The processor speed selected for the imbedded controller must be sized to
execute the code in the processors loop time.
There must be enough excess capacity designed in to handle external requests
from the system. One example of this is the CAN communication network on an
automobile where other modules (i.e. ABS, Cluster, Transmission, Service
Tools) request information from the engine control unite (ECU).
Whenever possible use the system clock to track time instead of loop time. An
example of this is a controller that monitors equipment for faults. A loop timer
might wait for 100 software loops of confirmed errors before setting a
diagnostic code. The processor loop time might be 10ms so a fault is detected
in 1000ms (1 second). When the software is placed in a new processor with a
5ms loop time, the fault will now be detected in 500ms (0.5 seconds) which will
change the test and could falsely set a code. If real time was used from a clock
then the 1000ms detection would be the same for either processor.
Key Points & Principles
Software Considerations
Physical Partitioning to Available Hardware
For systems with more than one processing unit or memory store facility, software
partitioning is an activity that, even when done early in the process, can take large
amounts of time.
At the core of this challenge is that there is often no single, best partitioning of a
system across all stakeholders for meeting various functional performance targets –
or sometimes even for one stakeholder.
Techniques using Pugh matrices and other concept-selection to determine a
weighted/scored basis for decision making often overlook integration implications of
each option. For example, a system where software for a particular function or
feature is spread across control modules or processors makes for an integrated
product that is harder to verify for correctness until all the disparate pieces are fully
assembled – or complex systems to stub/fake-out these interfaces until the actual
subcomponents are online.
Key Points & Principles
Software Considerations
Calibration & Tunable Parameters/"Hooks“
•
There is a limit to the amount of calibrateable values that should be used.
There is a trade off as calibrateable parameters are added to the software. The
more calibrateable parameters that are added decrease the software
development time, but they increase the calibration time.
•
Calibration parameters should be designed to be as uncoupled as possible.
Too many coupled calibration parameters will cause excess calibration time to
the point that optimization is not obtainable in the development time or is to
costly.
•
Using adaptive logic is a good way to reduce the number of calibrateable
parameters. Dynamically adapting to the changes of hardware as it wears and
ages gives an advantage over the fixed calibrateable parameter. A common
automotive example is adapting the fuel control using an exhaust oxygen
sensor to maximize the catalytic converter efficiency to reduce emissions.
Key Points & Principles
Software Considerations
Calibration & Tunable Parameters/"Hooks“ (Continued)
•
Make sure calibration recommendations are captured in calibration plan.
•
A key to flexibility are calibrateable (tunable) parameters which can be updated
in the software after or before the system is integrated. This allows the system
to be customized easily to multiple applications without requiring a software
change. A typical example of this would be the calibrateable parameters in a
ECU for engine displacement and number of cylinders. By making these values
calibrateable the same software can be used for an inline 4 cylinder or a large
V12 cylinder engine.
Processes & Tools
•
•
•
•
•
•
•
•
Introduction
Motivations for DfI
Key Points & Principles
Processes & Tools
Heuristics
Examples
Summary
References
MPD575 Weaver
65
Processes & Tools
•
•
•
System Design & Architecture Reviews
Change Control Processes
Modeling & Simulation Toolkits:
• Excel, Matlab/Simulink/Stateflow, LabView, etc…
•
Development Process Guides:
• Capability Maturity Model Integrated (CMMI)
• Software Process Improvement and Capability dEtermination (SPICE)
•
Version & Configuration Management Tools
• ClearCase, CVS, & many others
•
•
•
•
•
•
Process for System Architecting & Requirements Engineering
(PSARE)
Work Breakdown Structure (WBS)
Interface Matrices (e.g. 4-quadrant analysis matrix)
Boundary Diagram
Systems Vee
Design Structure Matrix (DSM)
Heuristics
•
•
•
•
•
•
•
•
Introduction
Motivations for DfI
Key Points & Principles
Processes & Tools
Heuristics
Examples
Summary
References
MPD575 Weaver
67
Heuristics
•
In partitioning choose the elements so that they are as independent as
possible, that is, elements with low external complexity and high internal
complexity. (Pg 170 The Art of Systems Architecting)
•
Test what intermittent signals will do to the system response. Usually it is
unexpected.
•
Do not route wires where they can be pinched.
•
Be aware that a nominal calibration is only nominal to the part used for
calibration. Take into account the variability.
•
Test the region outside the nominal calibration to make sure you aren’t on the
edge of instability.
Heuristics
•
The software does not age over time but the hardware does.
•
Pay close attention to the transient response of the system.
•
Test everything even if it does not seem like a rational customer will try it,
because they will.
•
Design the electrical system to be robust to extremely low voltage, otherwise
unexpected results will occur.
•
Avoid overlapping prototype phases
Examples
•
•
•
•
•
•
•
•
Introduction
Motivations for DfI
Key Points & Principles
Processes & Tools
Heuristics
Examples
Summary
References
MPD575 Weaver
70
Examples
•
•
•
•
•
Mars Climate Orbiter
Power-Up Power-Down Sequencing in a Vehicle
Butterfly Valve Control
Magnetic Stripe Card-Reader Application
Electronic Throttle Body Supplier Integration
MPD575 Weaver
71
Examples
Mars Climate Orbiter
Following the heuristic that “software doesn’t fail, but software designs do”, the
Mars Climate Orbiter was lost in September of 1999, after it properly executed a
propulsion command to enter Mars orbit after a 286 day, 461 million mile journey.
Unfortunately, due to a failure to clearly specify, check, and test the command
interface NASA’s JPL unit used to command the Lockheed Martin-designed
spacecraft, the spacecraft expected English units and JPL provided the command
in metric units.
This example demonstrates failure to specify, plan, and test at multiple levels –
long before even touching a single piece of hardware.
http://www.cnn.com/TECH/space/9909/30/mars.metric.02/
MPD575 Weaver
72
Examples
Power-Up Power-Down Sequencing in a Vehicle
How long does a typical automotive vehicle system have once a key is turned to
“start” to power-up, initialize, check communication bus readiness – including all
attached modules, check system status, and command an engine crank according
to current targets?
Given that it takes most people about 300-400 milliseconds to blink, if you blink
you’ll probably miss it.
For more recent Hybrid-Electric vehicles with an electric motor, high-voltage
battery, and internal combustion engine, this is even more challenging of a target
because that same time interval must include a preceding command to the highvoltage DC/DC converter to close high-voltage contactors (to provide proper
system bus voltage to power the starter motor) so that that system can respond
accordingly in the same interval.
This example is to illustrate the potential challenges of integrating even a welldesigned system, when so much happens in such a short period of time.
MPD575 Weaver
73
Example
Butterfly Valve Control
This is an example of an electronic butterfly valve that interfaces with a digital
controller. The position is fed back to the controller through an encoder and a
DC motor is driven by the controllers H-bridge. The hardware consists of a
circular plate attached to a shaft that has two springs applied in either direction
to keep a spring balance on either side of the plate.
Interface Changes
A new butterfly valve which integrates the spring balance into a single coil spring
was introduced to reduce the cost of the valve. All other aspects of the valve
were carryover, so there were no changes to the digital controller.
MPD575 Weaver
74
Example
Butterfly Valve Control (Continued)
Integration Testing
The new valve was hooked up to the controller and cycled through the full range of
motion. It was noted that halfway through the cycle the valve would oscillate
rapidly overshooting the desired position. The valve was examined and did not
have any defects, but it would always oscillate mid range.
Root Cause of Integration Issue
When the valve was redesigned to have one spring instead of two, there was a
known region in the middle of the valve travel that would not have any spring
force on it due to the design. This was not communicated to the software group
so no changes were made to the digital controller which always expected a
spring force. The controller would overshoot current in the region with no
spring force since it expected a constant torque on the shaft. The digital
controller was then updated to account for a region with no spring force without
causing oscillations. If the hardware performance change was captured in the
interface requirements between the two groups, the software could have been
redesigned upfront and on time.
MPD575 Weaver
75
Examples
Magnetic Stripe Card Reader Application
In late 2001, one of this DFX’s authors was involved in an undergraduate project to
design and build a embedded system to read, write, and process information from
student ID cards to provide improve a variety of student services such as quick
access to email, student cash-card balance, and similar services. Some of there
services required data submission or retrieval over the campus Ethernet.
Writing their own minimal (26 kilobyte) TCP/IP stack to support this, the team
decided to purchase a commercial off-the-shelf (COTS) embedded network
interface board, designed specifically for such embedded projects.
However, the network card purchased operated at a standard system voltage of 03.3 volts vs. the other common embedded system voltage of 0-5 volts. Having
overlooked this detail, the team decided to try and avoid reverse shipping charges
and replacement delays of 3 weeks by using “level translator” chips. Not only did it
take 2.5 weeks to get these level translator acquired, wired-in, and working, but
because of the further unanticipated delay, however small, that these translator
chips introduced into the system, communication across the system was never
achieved. It pays to pay attention to “minor” details.
MPD575 Weaver
76
Example
New Electronic Throttle Body Supplier Integration
Customer Need
The electronic throttle body on a car controls the torque produced by the engine. In
cold climates condensation can build up on the throttle plate which can freeze
when the engine is turned off. On older mechanical throttle’s the customer
would have to break the ice by firmly pressing on the accelerator pedal. In an
electronic system the Engine Control Unit (ECU) must break the ice, since the
accelerator pedal is not directly linked to the throttle body, by applying a large
current to open and close the throttle until the ice is cleared before allowing the
engine to start.
Electronic Throttle Body Icing Interface Requirement
The system design requires that the throttle body can withstand maximum voltage
(14 volts) alternating open and closed without wearing the throttle end stops by
X.X mm over 1000 cycles.
MPD575 Weaver
77
Example
New Electronic Throttle Body Supplier Integration (Continued)
Integration Test
The new electronic throttle body is cycled by the ECU +/- 14 Volts for 1000 cycles.
After the first four cycles an audible “crack” was heard and the throttle sticks
closed. The cover was removed and a number of broken gear teeth fell out of
the gear box.
Root Cause of Interface Issue
The supplier electronic throttle body was not designed to withstand motor torques
over 9 Volts. When the supplier agreed to the interface requirements they did
not test their part to determine if it was capable of running at 12 volts into the
stop. The supplier then had to redesign the thickness of the geartrain to
withstand the 12 Volts. The small oversight in voltage requirements cost 4
months delay in development.
MPD575 Weaver
78
Summary
If you get nothing else from this presentation –
remember considering, negotiating, specifying, and testing
interfaces is key.
References
Kossiakoff A., & Sweet W. "Systems Engineering Principles and Practice." Hoboken, NJ: John
Wiley & Sons, Inc., (2003).
Haskins C. "INCOSE Systems Engineering Handbook, version 3." International Council on
Systems Engineering (2006): INCOSE-TP-2003-002-03
Maier M., & Rechtin E. “The Art of Systems Architecting.” Boca Raton, FL: CRC Press LLC,
(2002).
Ulrich K., & Eppinger S. “Product Design and Development. Third Edition.” New York, NY:
McGraw-Hill/Irwin, (2004).
Stiffler K., “Design With Microprocessors for Mechanical Engineers.” Hightstown, NJ: McGrawHill, Inc., (1992).
Murray, Charles J. “Automakers: Electronic Content Still Rising”, Periodical
http://www.designnews.com/article/48839-Automakers_Electronic_Content_Still_Rising.php.
Design News. (October 2008)
Niggemann, Otterbach, Fleischer, & Jogi. “Using Software Architecture Models in
Automotive Development Processes”. SAE Technical Paper Series. 2008-01-2664
Other references cited throughout