MPD 575
Design for (Embedded Systems) Integration
DFI
Originally developed by:
Kyle Post
George Walley
Edits by Joe Torres, Criag Jozsa, Keith Warner, Mac
Lunn
An Integration Analogy
← Missing or overlooked pieces
Incorrect interfaces →
MPD575 Weaver
…but when done well…
MPD575 Weaver
Development History
December 2008 – Initially developed by K.Post & G.Walley (Cohort 9)
Hopefully not headed here
MPD575 Weaver
Design for (Embedded Systems) Integration
•
•
•
•
•
•
•
•
Introduction
Motivations for DFI
Key Points & Principles
Processes & Tools
Heuristics
Examples
Summary
References
MPD575 Weaver
Introduction
•
Introduction
–
–
–
–
–
•
•
•
•
•
•
•
Scope
Definitions
Relation to other disciplines
Stakeholders
Characteristics
Motivations for DFI
Key Points & Principles
Processes & Tools
Heuristics
Examples
Summary
References
MPD575 Weaver
Scope
Design for (Embedded Systems) Integration, or DFI, is about overcoming the
challenges of integrating complex electronic systems or the larger systems that
include them with the goal of reducing the cost and timing to assemble, test, and
tune the overall system.Pushing these development considerations earlier in the
design process, DFI will significantly reduce development time. However, while
such process changes are implemented and personnel trained, development time
may temporarily increase.
NOTE: The material covered is also naturally applicable to systems that do not
contain embedded electronic elements.
Exhaust Gas Oxygen Sensor
References:
Electronic Control Module
http://www.auto-diagnostics.info/images/ford_ee_iv.jpg
http://fordfuelinjection.com/images/hego.jpg
http://www.imagecows.com/uploads/_71ec-ford-engine.jpg
Internal Combustion Engine
MPD575 Weaver
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
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
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
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
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
o
DF Testability
MPD575 Weaver
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
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
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
–
Coordinating events and communication(e.g. engine spark/air/fuel, automated manufacturing &
things you can’t see)
assembly, TCP/IP)
•
Complexity Aspects
–
The same flexibility embedded systems afford also adds complexity(infinitely
adjustable/tunable, but finite time to actually calibrate)
–
Managing this complexity while hiding it from end users(e.g. plug-and-play computer devices)
MPD575 Weaver
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
– the integration efforts reduce this number, and new content increases again.
Development cycle has steps of integrate with volume of an architecture and
volume of modules, some never integrated at low volume
MPD575 Weaver
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 tomorrow’s
automobiles. This has materialized into multiple embedded controllers
managing the engine system, brake system, airbag 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
Motivations for DFI
Increasing Globalization
•
Many companies are expanding beyond original borders, whether just
locally or to other cities, states, and even countries.
•
Debates on outsourcing or insourcing 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.
– design practices of systems engineering also progress from text based
documents to models/state diagrams and smarter methods to overcome
language and translation issues/errors, CMMI levels, etc.
MPD575 Weaver
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
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 design of each component is done in a vacuum the integration
will not 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 set up correctly in the
initial design.
MPD575 Weaver
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 …
•
expanding to General Public License, Open Source and shared
platforms in the consumer devices of Ios(Apple), Android, etc.
MPD575 Weaver
Motivations for DFI
Insurance Against Loss of People-Assets
•
With well documented interfaces and standards for defining and
integrating systems, events like losing an 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
–
the use of model based SE for requirements, interfaces also helps with international,
supplier interactions, etc.
MPD575 Weaver
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
Motivations for DFI
Varying Operating Environments
•
Products need advanced 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.
•
The use of models and requirements from start are necessary to successfully use
the HIL, MIL, SIL discussed above.
–
Ford has use of IBM Rhapsody, Vector PREEvision SE and SA tools being applied. Can
allow use of data and transfer to/from the loop testing or MATlab/Simulink.
MPD575 Weaver
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
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
Verification
Integration / Test Plan
Detailed Design
MPD575 Weaver
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
Key Points & Principles
Design for Integration View of the Systems V
SEHandbookV3.pdf pg 4.11
MPD575 Weaver
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
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
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
becomes 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
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 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. Boundaries increases exponentially with the level of
the decomposition.
MPD575 Weaver
Key Points & Principles
Project Planning for Integration Activities
Organizational/Globalization Considerations
Reporting Structure
How an organization is structured determines what objectives and priorities various
engineering roles 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
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 locate, 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
• successfully doing this needs to move from paper/text design documents to models
and requirements that don’t need translation
MPD575 Weaver
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 embedded systems)
o
o
o
o
o
Systems Engineering & Systems Architecting Principles
Integrated vs. Modular
System Decomposition
Open vs. Closed
Interfaces
MPD575 Weaver
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 maximized. 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.
Example of exponential
complexity of integration while
moving to lower decomposition
levels (7 per level).
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
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 subsystems 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
C
B
Black Box
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 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 other hand, 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
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
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
Up-Integration
MPD575 Weaver
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. auto generated-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.
Note: Power need prediction is difficult from experience as moding of operation for
on, off, transition between duration, and the understanding of their own system.
The over specification of needs is very common and asking for a real number of
running vs starting load is not easy. Compromise on power of load shed to max
load available is also a ‘Not On My System discussion’, no one wants to lose power.
Key Points & Principles
Hardware Considerations
Up-Integration
Recent trends focus on combining unique pieces of hardware into a centrally
located single unit. Technological advances in electronics, software, and
communication protocols have enable this level of integration for the purposes of
reducing complexity/cost savings.
The single piece of hardware itself is a system, embedded with many uniquely
purposed software programs (such as a PC). The reduction in overall
complexity and cost can greatly outweigh the enabling increases required in the
areas of:
• Processing capability and memory size
• Packaging
• Power
6/13/2012
Keith Warner
Key Points & Principles
Software Considerations
Software for embedded systems controls 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”
Architecture
– Note: memory is cheap now and a “law” is that you should get more if you can and it will
be used! Having too much is shortly used in cycle actions, not having enough is a big
problem to churn chips later in design.
MPD575 Weaver
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 embedded 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 over specified 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 embedded 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 unit (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.
The execution of message and signals is also to be tied to clock, not loop time.
Example is the gateway message network modules that have latency, error
DTC’s in system for message not received/sent in time limits.
Key Points & Principles
Software Considerations
Physical Partitioning to Available HardwareFor 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 tunable (calibratable) values that should be used. There
is a trade off as tunable parameters are added to the software. The more tunable
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 too costly.
•
Using adaptive logic is a good way to reduce the number of tunable parameters.
Dynamically adapting to the changes of hardware as it wears and ages gives an
advantage over the fixed tunable 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 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 tunable parameters in a ECU for engine displacement and number of cylinders. By
making these values tunable the same software can be used for an inline 4 cylinder or a
large V12 cylinder engine.
Key Points & Principles
Software Considerations
Architecture
•
Along with Up-Integration, consideration must be given to the
software architecture to ensure a single piece of hardware is
capable of executing it. All SW should be of the same
operating system compatibility and/or level of security (open
source, proprietary, etc.)
6/13/2012
Keith Warner
Key Points and Principles (Cont.)
Recipe Guide for reducing unnecessary Chronometrics & RAM/ROM usage
1.
2.
3.
4.
5.
When a simple polynomial calculation based on a “curve fit” of data can be used in place
of a table, use it. A 2D/3D table takes up large amounts of memory and often times is
populated in a way that does not fully utilize the table anyway.
Always place software intended to enable/disable logic in the beginning of the algorithm it
is controlling. This prevents unnecessary computation of a feature that may not be
calibrated on to begin with.
Avoid advanced mathematical functions such as e^x or Ln(x) as they are processor
intensive and could be approximated with simpler functions if high accuracy is not
required.
Always start out with as few calibratable values as possible and try to develop the code to
not need calibration (auto-calibrate). This saves debugging time and in-vehicle time spent
getting the feature fine tuned. Apply realistic limits to cal values so that the size does not
get out of hand. Remember, you won’t be the only one tuning the feature.
For calculations that need to be performed only once during a key cycle, driving condition,
etc; design the code such that it only executes once. Executing complex algorithms that
result in an identical value after each loop is wasteful use of chronometrics.
An example is barcoding. The barcode characterizing a transmission clutch, for example, will
not change until the transmission is replaced. The logic only needs to be run once until a
technician forces it to run again.
Processes & Tools
•
•
•
•
•
•
•
•
Introduction
Motivations for DFI
Key Points & Principles
Processes & Tools
Heuristics
Examples
Summary
References
MPD575 Weaver
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
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 the system is not
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.
•
having the requirements and models for In Loop testing allows this range of testing
much easier than text documents!!!!
•
Design the electrical system to be robust to extremely low voltage, otherwise
unexpected results will occur.
•
Avoid overlapping prototype phases.
•
Recent Product Development cycles at Ford have not allowed this, the overlap to
achieve an overall shorter time is now established.
Examples
•
•
•
•
•
•
•
•
Introduction
Motivations for DFI
Key Points & Principles
Processes & Tools
Heuristics
Examples
Summary
References
MPD575 Weaver
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
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
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
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
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
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
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
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
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
Descargar

weaverjm.faculty.udmercy.edu