MODEL-BASED SYSTEMS ENGINEERING
OF AUTOMOTIVE SYSTEMS
Gerard H. Fisher, Vitech Corporation, Vienna, VA
tion, unit specification, trade-off study report,
Abstract etc.). When the SE passes a specification to the
For as long as systems engineers have hardware or software engineers, there is a tre-
been around, people have thought of them as mendous opportunity for miscommunication.
“paper pushers.” The primary products of sys- Because of the multiple meanings of English
tems engineers all seem to be documents such, words, it is easy to misunderstand the author’s
as specifications and trade-off studies. Com- intent. Furthermore, words are not the only re-
municating the requirements to hardware and quirements. Requirements may also come in
software designers with documents is fraught the form of relationships, attributes and dia-
with problems. By using a model-based ap- grams. It is very difficult to perfectly coordi-
proach to systems engineering, there is no am- nate all of these items. Using an object-
biguity. The model fully defines the functional oriented model-based tool, such as CORE®, for
behavior, inputs and outputs, and the physical system development will greatly aid the sys-
architecture, as well as the performance and tems engineer in this task.
resource requirements. This method provides a This paper discusses the mythical de-
unified, consistent and traceable design. sign of a automotive system to aid the driver
This paper describes the design of the through the use of Global Positioning System
Automotive Personal Assistance System (GPS) data. Cadillac offers such a system
(APAS) exploiting the features of the Global called OnStar. There are also several “after
Positioning System, which is similar to the market” versions available.
Cadillac OnStar System. It includes the entire
systems engineering life cycle, from source re- Originating Requirements
quirements analysis, through behavior analysis
Figure 1 illustrates the simple require-
and physical architecture, to verification and
ments for the APAS in the form of a context
validation. The behavior model can be fully
diagram. As the requirements are analyzed, it
executed to verify its correctness long before
is useful to draw such a diagram to help under-
money is wasted building prototypes. The use
stand the overall context for the system to be
of the model-based approach will aid in the re-
designed. The large ellipse represents the sys-
duction of product cost and the increase in
tem of interest. The smaller ellipses show the
external interfaces to our system. Key inputs
and outputs are shown as labeled arrows.
Introduction The APAS is required to perform the
Systems engineers (SE) have been pro- following:
lific producers of proscriptive prose. The SE’s
most prominent products are documents; the • Receive and process Global Positioning
heavier, the better. Systems engineers perform System data.
many tasks, but always convey their results in • Alert monitoring station of automobile
the form of a document (e.g., system specifica- accident
• Remotely unlock doors at owner’s re- • Alert monitoring station of auto theft
quest and current position
• Monitor & assess its own performance • Assist owner in finding car in parking
• Retain automobile position history for lot by sounding horn and flashing lights.
In this example, the customer came
back later with some additional requirements
(ECP #1), which added the following:
Assistance System Perform
Light & Horn
•Monitor Air Bag Deployment
•Monitor Impact Sensors (ISS)
•Notify CMS of Accident & Position
•Control Door Locking System (DLS) ts
•Monitor VPS, EDS, ISS Li
•Monitor & Assess Own Performance rn
•Retain 24-hour position history
•Act on Unlock Request
•Find Car in Parking Lot
ECP #1 Universe
Figure 1. APAS Context Diagram.
These requirements are analyzed by the Customer TBDs (to be determined) and am-
systems engineer and extracted. Compound biguous requirements will stretch the schedule
requirements are broken into simple statements. and add cost to a project. Once sufficient in-
Surely some of the requirements will be am- formation is obtained, the issue should docu-
biguous. Those ambiguities are usually han- ment the assumptions made, the alternatives
dled by creating an action item or issue. considered and the eventual decision, along
with the usual configuration control data. By
The issue describes the problem associ-
keeping the customer informed of these issues
ated with the originating requirement and as-
and diligently tracking them to conclusion, one
signs a severity, ownership and a due date.
can minimize the impact. Figure 2 illustrates
These ambiguities are perhaps the major im-
the requirements hierarchy for the basic re-
pediment to progress in the initial design phase.
quirements for APAS. It traces the require- level, implementable and verifiable require-
ments from their source specification through ments.
high-level compound requirements to the leaf-
incorporates incorporates incorporates incorporates incorporates incorporates incorporates
OR.1 OR.2 OR.3 OR.4 OR.5 OR.6 OR.7
Accident Automobile Monitor &
Diagnostics GPS Interface Retain History Unlock Doors
Response Interface Assess
OriginatingR... OriginatingR... OriginatingR... OriginatingR... OriginatingR... OriginatingR... OriginatingR...
incorporates incorporates incorporates incorporates incorporates
OR.1.1 OR.1.2 OR.5.1 OR.5.2 OR.5.3
Monitor Notify CMS of Assess Own Monitor Own
Accident Sen... Accident Performance Performance
OriginatingR... OriginatingR... OriginatingR... OriginatingR... OriginatingR...
Figure 2. Requirements Hierarchy.
lel. The functions have two types of inputs and
Behavior Modeling outputs shown. Those with only a source or a
Once all requirements have been ex- destination are called data stores. The data is
tracted, analyzed and understood, it is time to assumed to be available whenever it is needed.
postulate one or more functional models that The other type of data element is called a data
would fulfill these requirements. All require- trigger. A data trigger is generated by one
ments should trace to a function. If you end up function and sent to one or more other func-
with functions that do not trace to a require- tions. The functions requiring the data trigger
ment, the function may be superfluous. If, on cannot begin until it arrives. This feature per-
the other hand, you find requirements without a mits the E-FFBD to be simulated.
corresponding function, your model is incom- The use of a discrete event simulator is
plete. The models should be constructed in very helpful in verifying the logical correctness
layers. The top layer should be similar to the of the design. Whenever possible, a systems
context diagram described above. engineer should postulate two or more behavior
An example of such a high-level model models and trade them off to select the best de-
is shown in Figure 3, in the form of an en- sign. The simulator is one of the tools that will
hanced function flow block diagram (E-FFBD). aid in these trade-offs. However, this type of
The system under design is “Operate APAS.” trade-off requires the combination of economic,
The other functions shown represent the exter- performance and subjective data to arrive a sin-
nal interfaces to APAS. These include the GPS gle figure of merit. Another technique that
interface, the door lock system in the car, the would be useful for this task is the analytic hi-
automobile’s electronic diagnostic system erarchy process (AHP).
(EDS), automobile’s horn & light systems, and
the customer monitoring station (CMS) that
supports calls for help. The and construct in-
dicates that all functions are operating in paral-
C.1 C.2 C.3 C.4 SYS.1
Perform GPS Customer Door Locking Global Electrical Automotive
Functions Monitoring Sy... System Positioning Sy... Diagnostic S... Personal Assi...
Component Component Component Component System
SS.1 SS.2 SS.3
Positio... Receiver Data Transmitter
Subsystem Processing S... Subsystem
Component Component Component
C.2 Find Car APAS Data Data
Processor Processing So...
Perform Component Component
System Auto Auto DP.1 DP.2 DP.3 DPSW.1 DPSW.2 DPSW.3 DPSW.4
Lock ... Unlock GPS DP Subsystem Crash Position Request System
DP CPU DP Memory
Positio... Case Identification History Mana... Validation Diagnostics
Component Component Component Component Component Component Component
Opened Figure 4. Physical Design Hierarchy.
AND System AND OR.1
Perform incorporates incorporates
Status Monitor Accident Notify CMS of
causes traces to traces to traces to traces to
R.1 F.3 F.4 F.6 F.7
C.4 Monitor for Monitor for ISS Get Position Notify CMS of
Airbag Deploy... Deployment History Accident
Functions Risk Function Function Function Function
resolved by allocated to allocated to allocated to allocated to
CON.1 DPSW.1 DPSW.1 DPSW.2 SS.3
Crash Crash Position History Transmitter
Identification Identification Management Subsystem
Constraint Component Component Component Component
Figure 5. Traceability from Requirements to Components.
Figure 3. Functional Context Diagram.
AHP is a form of multi-attribute deci- when they have allocated function to the spe-
sion analysis, developed by Dr. Thomas Saaty cialty (HW or SW). Let the specialty engineer
in the early 1970’s. AHP includes development make the design and implementation choices
of a hierarchical model of the criteria to be used below that level. This is not to imply that the
in a decision and then develops a set of relative specialty engineers should use a different
weights using a pairwise comparison method. method. They can and should stay with the
The SE might make a series of Monte Carlo same model-based approach throughout their
runs for each proposed behavior model, meas- design phase. When the hardware engineers are
uring task times, wait times, queue sizes, etc. ready to design VHDL (the hardware language
These results, along with other measures and used to specify design) and the software engi-
estimates, could be plugged into an AHP model neers are ready to code, they can just export the
to determine the most compliant design. design from the tool. There are several tools
that interface with VHDL and code generators.
As a final check of your design, Figure 5 shows
you a trace from specific requirements through
Once a preferred behavior is selected, functions to physical components. The inverse
the SE can begin developing several physical would ensure that all physical components had
designs. As part of the physical design, the a reason for being in the design. If they could
systems engineer will allocate functions to not be traced back to a specific requirement, the
hardware, software, and humans. These are the component might be unnecessary.
three types of physical components in a system.
The way in which these three function together
is the system or process. In a similar fashion to Verification and Validation
the process above, these designs should be During the requirements analysis phase,
traded off to select the preferred design. If one a key step is the assurance that compliance with
were to give the same requirements and be- a requirement can be proven. If not, the re-
havior model to three experienced systems en- quirement is not valid and the issue should be
gineers, the results would be three unique sys- resolved with your customer. If the require-
tem designs. There are always some obvious ment can be verified, then a high-level verifi-
choices for software implementation or hard- cation requirement should be generated during
ware implementation, but some require serious the requirements analysis phase. You have
trade-offs. This could be another application though it out and it is a good idea to record it
for the AHP. Some of the key parameters one while it is fresh in your mind. For instance, if a
considers in physical design trade-offs are cost requirement specified a 95% isolation of all
(both initial and recurring), power consump- hardware faults to a single circuit board, you
tion, performance, reliability, maintainability, might specify the verification requirement
supportability, technical risk, etc. Figure 4 il- “verify 95% fault isolation to a single circuit
lustrates the physical design hierarchy for board by doing 100% fault insertion on all in-
APAS. The interfacing systems are numbered put / output pins on the board.” This would
C.1 through C.4. Our system, SYS.1, has three give you enough information to be able to esti-
major subsystems: receiver, transmitter and mate the cost of the effort. When detailed test
data processing. The data processing subsys- planning is done, that verification requirement
tem is comprised of both hardware (the data would be expanded to describe a verification
processor) and software (the data processing event, assign a responsible individual, develop
software). Each of these can then be broken a test plan and procedure, and identify the test
down to as low a level as necessary. However, configuration needed to perform such a test.
the systems engineers should cease design
satisfied by verifies
assigned to defined by documented by uses configuration traces to traces to verified by
RO.2 TPR.1 TPL.1 TC.1 F.3 F.4 V.1
APAS Test Monitor for Airbag Monitor for ISS Accident Sensor
Test Conductor APAS Test Plan Test Config 1
Procedure Deployment Deployment Test
ResponsibleOr... TestProcedure Document TestConfigurat... Function Function VerificationRequ...
formed by formed by formed by formed by formed by formed by formed by formed by formed by formed by formed by
SS.3 CMS.L.2 DUL.L.1 GPS.L.1
System Status Door Unlock
Data Processing Transmitter GPS Link
Component Link Link Link
DP SS.1 CMS.L.1 CMS.L.3
EDS System Automotive
APAS Data Receiver Accident Unlock Request Status Link Personal Assist...
Processor Subsystem Notification Link Link
Component Component Link Link
Figure 6. Verification Hierarchy.
Figure 6 illustrates the verification hier- large systems, where test resources are at a
archy for the APAS Accident Sensor Test. In premium. Being able to identify the equipment
addition to the information described above, it needed will permit scheduling of tests to avoid
also identifies the requirements and functions to conflicts.
be verified. This becomes especially useful in
Primary Concurrent Proposal Activities At Each Layer
Originating Behavior Synthesis/ Design Publish &
Requirements Analysis Architecture V&V
Source System Design Database Specification & Report Generation
and RFP Iterate as Required When Layer Completed
Behavior Synthesis/ Design Publish &
for this layer are Analysis Architecture V&V Evaluate
embodied in the
model passed from and
the prior layer
System Design Database Specification & Report Generation •
Iterate as Required When Layer Completed •
Behavior Synthesis/ Design Publish &
Initial Requirements Analysis Architecture V&V
for this layer are Evaluate
embodied in the
model passed from Accept Handover
From Prior Shift
Process Claim Quiting time?
OR LP Leave Workplace
the prior layer
yes Handover to Next
System Design Database Specification & Report Generation Proposal)
Figure 7. The Onion Model.
tomer might come to you and ask for the impact
The Onion Model of making some upgrades to the system. With
Figure 7 illustrates the recommended an up-to-date model, such an analysis is almost
method for doing model-based design. First trivial.
extract high-level requirements and develop a
high-level model for behavior. Then develop a Biography
corresponding high-level physical design and
Gerard H. Fisher is a Member of the
verification and validation (V&V) plans. Trace
Technical Staff at the Vitech Corporation, in
requirements to the model, design, and V&V to
Vienna, Va. He provides consulting services
ensure all requirements were addressed. This is
on the application of CORE® to support sys-
a complete design and would greatly assist your
tems engineering, decision analysis, product
team in understanding and reviewing its com-
development and program management. Prior
pleteness. Then proceed to the next level of
to joining Vitech, Mr. Fisher was the corporate
abstraction in the requirements, model, design,
Director for Enterprise Process Improvement,
and V&V. This process should be continued
for CACI. For 25 years, Mr. Fisher was a Sen-
until all requirements are addressed.
ior Systems Engineer at IBM Federal Systems
(and Loral after the acquisition) in Manassas,
Summary Virginia. He was involved in systems engi-
The model-based approach to systems neering on the Advanced Ballistic Missile De-
engineering offers clear advantages over the fense System and several high-performance
traditional paper-driven approach. The most signal processors for federal customers. He
obvious is that the database containing the chairs the International Council on Systems
model becomes the “corporate memory” for the Engineering (INCOSE) System Reengineering
project. Systems engineers change jobs often Working Group and is Technical Chair for the
and take their project knowledge with them. INCOSE WMA Chapter. He received his B.S.
With all rationale and decisions in the database, in Physics from St. Bonaventure University and
the knowledge stays with the project. Docu- M.S. in Systems Engineering from Virginia
ments get lost and one is never sure whether the Tech.
copy you have is the most up to date. This is
not a problem with the model-driven approach.
The model also permits “what-if” analy-
sis later. After the system is fielded, the cus-