IEEE SYSTEMS JOURNAL, VOL. XX, NO. X, MONTH 2015 1

Cyber-Physical Co-Design at the Functional-Levelfor Multi-Domain Automotive Systems

Jiang Wan1 Student Member, IEEE, Arquimedes Canedo2 Member, IEEE,and Mohammad Abdullah Al Faruque3 Member, IEEE

Abstract—Software-integrated multi-domain automotive sys-tems – also referred to as automotive Cyber-Physical Systems(CPS) – consist of various interacting domains (software, hard-ware, multi-physics, communication, etc.). Design decisions in onedomain may completely change the constraints and requirementsin the other domains, e.g. adding more functions in a modernautomotive CPS may require changes to thousands of lines ofsoftware code or even the mechanical architecture. Existing CPSdesign methodologies are siloed in a specific domain and thereforehave limited design space exploration capabilities, because onlyone domain can be tested at a time. This paper presents afunctional-level cyber-physical co-design methodology startingfrom the functional model of the CPS capable of concurrentlyexpressing (multi-)physics and control in automotive applications.Moreover, we introduce a high-level synthesis algorithm capableof selecting a set of optimized system architectures using variousexecutable simulation components and cost metrics. We demon-strate our methodology with a realistic automotive use case andexplore various design alternatives for implementing the controlsystems in pure continuous domain (e.g. traditional automotivesubsystems without ECUs) or hybrid domain (e.g. Brake-By-Wire(BBW), Steer-By-Wire (SBW), Drive-By-Wire (DBW), etc.) underpower, performance, and reliability constraints.

Index Terms—Automotive Engineering, Cyber-Physical Co-design, Functional Model, Design Automation, Systems Engineer-ing.

I. INTRODUCTION

AUTOMOTIVE Cyber-Physical Systems (CPSs) are hy-brid (continuous and discrete dynamics), heterogeneous

(component variations), multi-domain systems consisting ofvarious embedded systems, and physical processes connectedthrough communication networks. The complexity in the mod-ern automotive design is attributed, for the most part, to thesoftware integration [8, 21, 25] during the engineering stage.Today, 90% of all the automotive innovations come from theelectronics and software; and 40% of the development costscome from the Electronic/Electric (E/E) systems [13]. Unfor-tunately, the software integration in the automotive design isperformed after the physical architecture has been decided.This is not an optimal method for various domains and also acounter-intuitive methodology for the design of CPSs because,in principle, CPSs are supposed to be tight integrations of“cyber” and “physical” processes. In our opinion, the state-of-the-art automotive design methodologies should be revisited

1Jiang Wan is with the Department of Electrical and Computer Engineering,University of California, Irvine, CA, 92617, USA.

2Arquimedes Canedo is with the Siemens Corporation, Corporate Technol-ogy, Princeton, NJ, USA.

3Mohammad Abdullah Al Faruque is with the Department of Electrical andComputer Engineering, University of California, Irvine, CA, 92617, USA.

in such a way that the software integration is validated asearly as possible, and in parallel with the design of the restof the system. This means that new design tools [9] shouldprovide the cyber-physical design capabilities to fully exploitthe benefits of software integration for increased performance,reliability, and decreased power, price, and time-to-market.

During the early design stage (aka concept design stage)1,detecting and fixing errors is 5X to 10X less expensive andproblematic than in the latter detailed design stages [12].Therefore, it is highly desirable to validate CPS design asearly as possible. However, the existing CPS design toolsstay at the domain-specific levels [4, 10, 26] and this inhibitsthe possibility of appropriately handling the cross-cuttingconcerns that characterize CPS. For example, the early designof an automotive requires an experienced designer with abroad multi-domain knowledge to manually make decisionssuch as: should the control be implemented in a traditionalcontinuous domain architecture or in an E/E hybrid-domainarchitecture? If E/E architecture is selected, what will bethe minimum cost for the digital hardware implementation?What are the additional costs of sensors and actuators? Areadditional continuous-domain electro-mechanical componentsrequired for implementing this control strategy?

State-of-the-art system-level automotive CPS co-designtools are currently missing, but are heavily desired by au-tomotive industry [9]. Therefore, to answer these questionsas early and as accurately as possible in the early conceptdesign stages, this paper proposes a new functional-level co-design methodology that emphasizes breadth – knowledgethat spans across disciplines – rather than depth – knowledgethat focuses on a particular domain – as it is the focus ofthe existing design tools. Our methodology starts with thefunctional models which formalize the requirements of a newautomotive CPS functional models define, at the early designstage, what the system does in terms of energy, material,and signal flows. From a design automation perspective, thisfunctional-level abstraction is a suitable formalism for CPS co-design because it decouples the intent (functionality) from itsimplementation (e.g., E/E vs electro-mechanical architectures).For example, an engine system’s functionality is to convertchemical energy contained in the fuel into mechanical energyand hot gases. Given this functionality, several architectures,such as the traditional mechanical control system with driverand pedals or the modern E/E systems with many sensorsand ECUs [21], from multiple domains may be applied. In

1In systems engineering, early design stage identifies the overall function-ality and structure/architecture of a new system or product [7, 20].

IEEE SYSTEMS JOURNAL, VOL. XX, NO. X, MONTH 2015 2

this paper, we demonstrate the applicability of our functional-level co-design methodology with a real automotive exampleto highlight the importance of having a system-level DesignSpace Exploration (DSE) capability during the early designstage of an automotive system. The novel contributions of thispaper are summarized as follows:

1) A functional-level co-design methodology for reducingthe design time through the DSE and identification ofoptimized architectures for the automotive CPS. Thisassists the designer to decide how, when, and what partsof the system should be integrated with software/cyber-based control to achieve the optimal system performance.

2) A modeling technique for partitioning control and (multi-)physics explicitly at the functional-level in order to sup-port a fine-grain cyber-physical co-design for automotiveapplications.

3) A new high-level synthesis algorithm for supportingcyber-physical co-design from the cyber-physical func-tional models, where the control may be mappedto software-centric digital systems and/or conventionalphysical systems, to a set of optimized system architec-tures.

4) A companion set of cost metrics to verify the cost of thearchitecture models from different perspectives such as:performance, reliability, robustness, energy, weight, size,price, and emissions.

5) A complete case-study analysis using a real automotiveapplication that demonstrates the advantages of our pro-posed co-design methodology.

The rest of the paper is organized as follows: Section IIuses a motivational automotive example to expose the needfor early stage DSE capabilities. Section III introduces ourfunctional-level co-design methodology. Section IV presentsan automotive DSE case-study. Section V discusses the maindifferences of our methodology relative to the related work.Finally, section VI concludes the paper.

II. MOTIVATIONAL CASE-STUDY

One of the major challenges in designing a CPS is the inte-gration of system-of-systems in such a way that performanceand budget targets are met. For example, the steering system inan automotive is a critical sub-system with a relatively simplefunctionality; but it has dozens of different implementations.Figure 1 shows two typical architectures of the steeringsystem: Figure 1 (a) shows the traditional Hydraulic Power-assisted Steering (HPS) architecture [30], and Figure 1 (b)shows the recent Steer-By-Wire (SBW) [19] architecture. Inboth architectures, a human driver is involved and acts as themain controller of the whole system. Furthermore, a Torsionbar connected to a Gearbox, and two wheels are commoncomponents in both architectures. The connections betweenthe Torsion bar, Gearbox, and two wheels are mechanical con-nections since these components are all from the mechanicaldomain.

The difference between these two architectures lies in howthe assistance-power is provided. In the HPS, a Mechanicalamplifier and a Pump connected with a Hydraulic pipe provide

Steering

wheel

To

rsio

n b

ar

Mechanical

amplifier

Valve

Hydraulic

pipePump Gearbox

Right wheelLeft wheel

Driver

Steering

wheel

To

rsio

n b

ar

Speed

sensorECU

PID circuit

DC

motorGenerator Gearbox

Right wheelLeft wheel

Other

sensors

Driver

(a) Hydraulic Power assisted

Steering (HPS) architecture

(b) E/E Steer-By-Wire system

(SBW) architecture

Fig. 1. Two example architectures for the CPS functional model of theautomotive steering system.

the assistance-power. Since these are all mechanical domaincomponents, most of the connections between these are me-chanical connections without sensors and actuators. Only aValve between the Mechanical amplifier and the Hydraulicpipe is required to act as the actuator that transfers a controlsignal in mechanical domain into hydraulic domain. In theSBW, an E/E subsystem with an ECU and a Generator con-nected to a DC motor provide the assistance-power. Moreover,a Speed sensor connects the Torsion bar and the ECU becausecontrol signals in the mechanical domain need to be transferredinto E/E domain in order to control the DC motor. Finally,a PID circuit is implemented as an actuator to connect theECU and the DC motor to convert control signals from theelectronic domain to the electro-mechanical domain.

-500

-300

-100

100

300

500

0 1 2 3 4

Fo

rce

ap

pli

ed

on

wh

eel (N

ew

ton

s)

Time (Seconds)

HPS (Continous control)

SBW (Hybrid control)

2.54 3.94

0

2

4

6

8

10

12

14

0 1 2 3 4

En

erg

y c

on

su

mp

tio

n (

kil

ojo

ule

)

Time (Seconds)

HPS (Continuous control)

SBW (Hybrid control)

0.4s

(a) Steering reaction-time (b) Total energy consumption

Energy saving with SBW

Fig. 2. Performance and power consumption comparisons for the software-centric (SBW) and electro-mechanical-centric (HPS) automotive architectures.

These two architectures are compared to answer the designquestions such as which architecture has better performanceand less energy consumption. The performance is measuredby the reaction time, which indicates how quickly a systemresponds to a change in its inputs. In the HPS, we observethat there is a major delay from the Mechanical amplifier tothe Hydraulic pipe because the mechanical devices have a rel-atively larger response time when compared to the electronicdevices. In the SBW, the Speed sensor, ECU, and the PIDcircuit are electronic devices. Therefore, we observe that the

IEEE SYSTEMS JOURNAL, VOL. XX, NO. X, MONTH 2015 3

SBW has a smaller reaction time. Experimental results2 inFigure 2 (a) confirm that the HPS has 0.4s additional delaywhen compared to the SBW. Furthermore, we also notice thatsince in the HPS, the Pump is always working – even withouta steering signal – it has a higher power consumption than theSBW. Experimental results in Figure 2 (b) shows that the HPShas high and roughly constant power consumption while theSBW has a more efficient power consumption.

Although the SBW has better performance, it may havesignificant reliability and safety concerns when compared tothe HPS (a quantified analysis is provided in Table III inSection IV). Mechanical components, in practice, are con-sidered error-free within the expected lifetime [8]. Howeverthe E/E components such as ECUs and Speed sensors mayintroduce potential failures that affect and propagate to theentire system. To minimize the safety concerns introducedby the E/E components, more reliable hardware and softwareare required, and these additional hardware and softwareconsequently increase the overall system cost [25].

Today, it is well understood that the SBW systems have ahigher performance but are more expensive and have a higherrisk of safety-related issues (our experiments in Section IValso validate similar results). However, as of today, there isno systematic method to decide between deploying software-based control and traditional non-software-based control invarious sub-systems of an automotive system; nor are toolsavailable to help designers quantify the costs (defined inSection III-D) of such design alternatives through rapid DSE.

III. CYBER-PHYSICAL CO-DESIGN

From the example presented in Section II, we analyzehow the control behavior may be implemented in either thecontinuous domain (HPS system) or in the discrete domain(SBW system). There is a broad design space that allowsfor a variety of implementations of the control behaviors. Inthis section, we propose a computer-aided, functional-levelco-design methodology that supports the DSE of the controlbehavior from a new level of abstraction (cyber-physicalfunctional-level). Before going to the details of the design flow,we first provide several definitions that will help to explain ourmethodology.

A. Definitions

Definition 1. A functional model is a formal description of thefunctional requirements for a system. It is defined as a labeledgraph FM = (F,E,LF , LE), where each node fi ∈ F is afunction, each edge e(i,j) ∈ E represents the flow from fito fj . Each function f ∈ F and flow e ∈ E have uniquelyassigned labels l(f) ∈ LF and l(e) ∈ LE describing the typeof the function f and flow e using a standard vocabulary.

The vocabulary may be from any functional descriptionlanguage. In this work, for simplicity, the Functional Basislanguage [18] is used for describing the functions and flows.

2Experiments are performed using the state-of-the-art automotive systemsimulation tool Amesim [1].

A CPS functional model is an extension of the functionalmodel that partitions and specifies the control and physicalprocesses explicitly. The vocabulary used in CPS functionalmodel may be the same as defined in the functional model. Thedetailed definitions of CPS flow, control specification blockand physical process block are provided in Definitions 3,4,6.

Definition 2. A CPS functional model is a formal descriptionof both the control specification and the physical processof a system. It is defined as a labeled graph CPS ={C,P,E,A,L(C), L(P ), L(E), L(A)}, where C is a set ofcontrol specification blocks, P is a set of physical processblocks, E is a set of CPS flows connecting C and P , andA is a set of architecture blocks. Each control specificationblock c ∈ C, physical process block p ∈ P , flow e ∈ E, andarchitecture a ∈ A have uniquely assigned labels l(c) ∈ L(C),l(p) ∈ L(P ), l(e) ∈ L(E), and l(a) ∈ L(A) describing theirfunctions/specifications.

Definition 3. A CPS flow has three types: signal, energyand material. Signal flows are used to model the control-related signals such as the sensing-data and the control-commands. Energy and material flows are used to model theflows with real physical properties such as mechanical energy,electrical energy, fuel and gas, etc. For each flow, a labelis attached to describe its detailed specification using a pre-defined vocabulary.

Definition 4. A control specification block models the controlspecification for a specific physical process. A control spec-ification block takes signal flows (sensing-data and control-communication) as inputs and generates signal flows (controlcommands) as outputs. For each control specification block, alabel is attached to describe its detailed specification using apre-defined vocabulary.

Definition 5. A control behavior describes the detailedlogic/behavior of a controller that satisfies a given controlspecification. Given a finite number of states X , inputs U andoutputs V , it is defined as the function f that f : (X,U)→ V .

The control behavior is used to describe the controlalgorithm in a control specification block. The function fcan be described using various Models of Computation (MoC)such as finite-state machine or programming language.

Definition 6. A physical process block models a real-worldprocess on energy and materials. The description of the physi-cal process follows the same vocabulary used in the functionalmodel. The prime flow types of a physical process block areenergy flow and material flow. Besides, a physical processblock also receives control-commands inputs and providessensing-data outputs in the form of signal flows. For eachcontrol specification block, a label is attached to describe itsdetailed functions using a pre-defined vocabulary.

Definition 7. An architecture block is a placeholder that iscreated during the early design stage. A label describing thetarget architecture of this block is given by the domain-specificengineers. It can only be implemented by the architecturehaving the same label.

IEEE SYSTEMS JOURNAL, VOL. XX, NO. X, MONTH 2015 4

Synthesizephysical function

Cyber scheduling

Functional description

Control-physics partitioning

Refinementsupport

Synthesize blocks

System description

Synthesis stage

Architecturesimulation

Library ofcomponents,architectures,

andcommunication

protocols

Synthesizecontrol specification

Synthesizecontrol behavior

Synthesize flows

CPS functional model

Architecture simulation

Costcalculation

Control specification block

Physical process block

Multi-domainarchitecture model

Multi-domain architecture model(SBW architecture)

Architecture simulation model (AMESim platform)

CPS functional model

Control specifications using LTL

Synthesis processPhysicalControl

Fig. 3. Proposed co-design methodology for automotive CPS. The right half of the figure describes the detailed steps of the proposed co-design methodology.The left half of the figure gives a synthesis example of a steering system (CPS functional model → Multi-domain architecture model → Simulation model).

For example, an architecture block “Steering wheel system”is expected to be directly mapped to an existing “Steeringwheel system” architecture. The vocabulary of the labels maybe defined by the domain-specific experts manually.

Definition 8. An architecture model is a synthesized systemarchitecture. The architecture model is a graph AM = (C,E),where C is architecture component mapped from the blocks inCPS functional model and E is the inter-components commu-nication/connections mapped from the flows in CPS functionalmodel. Moreover, each E has a label L(E) indicating the typeof the communication/connections.

The type of the communication/connections can be fromdifferent domains, for example electronic communication pro-tocols, mechanical connections, etc.

Definition 9. A cost of an architecture arch is a value repre-senting the penalty of an architecture on a specific perspectivepes. The cost value Costarchpes is calculated based on a set ofpre-defined cost models.

In this paper, we propose a set of cost models from severalperspectives in Section III-D. In the proposed cost model,bigger value of the cost indicates larger penalty on anyperspective.

B. Co-Design Flow

The proposed co-design flow as presented in Figure 3 hasthree steps: 1) system description, 2) synthesis stage, and3) architecture simulation. During the system description,a control-physics partition is specified to create a CPS func-tional model from the given functional models/specifications(see details in Section III-C). The CPS functional model isthe input for the synthesis stage, where blocks and flowsare synthesized into models of components stored in thecomponent libraries using the algorithm proposed in Sec-tion III-E. The library consists of physical components in-cluding sensors/actuators, cyber components such as micro-controllers/communication networks, and existing architec-tures that may be directly mapped to architecture blocks. Aschedule sub-step is involved to manage the scheduling of thecontrol tasks and the communications3. When a set of archi-tecture models are synthesized, the algorithm calculates andcompares the costs of the architecture models from differentperspectives (see details in Section III-D). Based on the user-defined requirements, a set of architecture models are selectedas the outputs of the synthesis stage to reduce the designspace. Finally, in the architecture simulation, the generatedarchitectures are simulated to validate that they fulfill all the

3Details of scheduling the control tasks are out of the scope of this paper.However, we discuss the related work in Section V.

IEEE SYSTEMS JOURNAL, VOL. XX, NO. X, MONTH 2015 5

given requirements. If the simulation results are satisfactory,the output architecture models are integrated into the libraryand refinement suggestions may be provided to the designersfor further improving the CPS functional model.

C. Control-Physics Partition

Functional modeling has been shown to have the ability ofmodeling both the continuous and discrete domains at the samelevel of abstraction [5, 6, 18]. However these methodologiesover-emphasize the modeling of physical processes and do notfully satisfy the modeling requirements for cyber-processes.To overcome these limitations and find a more appropriateformalism for the modeling of complex control systems thatare integrated to multi-physics systems in the functional mod-eling, we propose to explicitly partition control and physics atthe functional-level.

In our CPS functional model, we use two pre-definedtypes of blocks: 1) the control specification block and 2)the physical process block. During the system descriptionstep, both control and physical process blocks are defined.If the function involves a control behavior, a pair of blocksare defined: the control specification block c, and a physicalprocess block p, with flows between them. If f does notrequire a control behavior, we simply convert f into a single pwith the necessary flows. Additional flows required to connectall the blocks are also created during this step.

Convert

Human E.

Convert RME

to TME

Steering

signalRME TME

Store DriverDriver

Human

Energy

Convert *E

to RME

*E

RME

Convert *E to

RME

Convert

controller

*E RME

Convert

RME to TME

Convert

Human E.

RME

Human

Energy TME

Driver

controller

Store Driver

Control-physics partition

Control signal flow

Material flow

Energy flow

Physical process block

Control algorithm block

Functional description

CPS functional model

Fig. 4. Control-physics partitioning of the steering system.

A control-physics partition example from the functionalmodel to CPS functional model is presented in Figure 4. No-tice that the syntax and semantics of the functions of a systemcan be described using various existing functional modelinglanguages (Functional Basis language is used in this paper).This example shows four functions: the function Store driver ispartitioned into the Store driver and the Driver controller; the

Convert *E (Energy) to RME (Rotational Mechanical Energy)4

is partitioned into a physical process Convert *E to RME andthe Convert controller. Notice that, in this example, other twofunctions, Convert RME to TME (Translational MechanicalEnergy) and Convert Human Energy, do not need to becontrolled, thus they are partitioned into physical processeswithout controllers.

Control Specification Description: To describe a controlbehavior (see Definition 5) requires an existing dynamic be-havior (in the form of mathematical equations) of the physicalprocess under control [3]. In order to model the control withonly a high-level functional abstraction of the physical process,a method for describing the higher level control specification isrequired. Existing work [37] has shown that Linear TemporalLogic (LTL) may be used for the control specifications, andfurthermore, tools and algorithms [28, 37] are available tosynthesize LTL into control behavior described in the formof finite-state machine and/or other MoCs. In this paper, weuse LTL for the control specification.

Physical Process Description: As defined in Definition 6,to describe the physical process block, a high level languagewhich may capture the domain-independent functions of aspecific physical process is required. Existing work [5, 6, 35]have shown that the Functional Basis language is a suitablecandidate for describing the physical process. As a result, inthe scope of this work, we use the Functional Basis languageto describe the physical process of the CPS functional model.

D. Cost Metrics

Selection of a specific architecture for an automotive designdepends on various non-functional requirements and/or associ-ated design costs. Therefore, the synthesis algorithm needs toautomatically validate the system from different perspectives.Each perspective is mapped to the user requirements. Forany valid design, the cost from any perspective must notviolate the corresponding requirement. The validation for thecost Costarchpes of the architecture arch depends on the costfunctions fpes(C) on a specific perspective pes as shown inEquation 1, where C is the set of all the components in arch.

Costarchpes = fpes(C); (1)

In our current work, we use various cost functions fpes(C).From the performance perspective, based on the executiontime of the control tasks on the specific controllers and thereaction time of the physical process, fperf calculates the totaldelay of each path in the graph of the architecture. We assumethe number of paths in the graph is n and the delay of anycomponent ci is τi and Costarchperf is the largest number of allthese delays as shown in Equation 2.

Costarchperf = max(∑

ci∈path0

τi,∑

ci∈pathn

τi) (2)

From the reliability perspective, assume that the failurerate of each component ci in the architecture model arch is

4We use *E to denote any general types of energy, it means that *E maybe in any form such as: mechanical, chemical, or biological energy.

IEEE SYSTEMS JOURNAL, VOL. XX, NO. X, MONTH 2015 6

a function of Mean Time Between Failure (MTBF) of eachci: FRi(MTBF ) = 1/MTBF . We define Costarchrel as thefailure rate of the whole system (see Equation 3).

Costarchrel = 1−∏

ci∈arch

(1− FRi(MTBF )) (3)

The robustness cost Costarchrobust is used to indicate thequality of the whole architecture under different environments.We calculate the robustness cost based on the reliability cost,Costarchrel . Given any environment E, the failure rate of eachcomponent ci is modified to be environment depended asFRi(MTBF,E) and the reliability cost is a function ofenvironment Costarchrel (E). Currently, Costarchrobust is calculatedby the ratio between two reliability costs under the harshenvironment Eharsh and the normal environment Enorm (seeEquations 4). Enorm and Eharsh are defined by the designersas requirements.

Costarchrobust = Costarchrel (Eharsh)/Costarchrel (Enorm) (4)

For the power consumption cost, Costarchpower, we identifyall the energy flow inputs εi and outputs εo of the architecture.Costarchpower is calculated using the power efficiency, defined asthe total output power Powerεo divided by the total inputpower Powerεi as presented in Equation 5.

Costarchpower = Powerεo/Powerεi (5)

For price, weight, size, and emissions, we model thecosts for each component, ci as a separate property p, w, s, e.Therefore, Costtotal of the synthesized architecture is the sumof individual components on each perspective shown below:

Costarchprice =∑

ci∈arch

pi (6)

Costarchweight =∑

ci∈arch

wi (7)

Costarchsize =∑

ci∈arch

si (8)

Costarchemission =∑

ci∈arch

ei (9)

E. Cyber-Physical Co-Synthesis Algorithm

In this subsection, we present our algorithm for syn-thesizing functional model into architectures in detail. Theinputs to the cyber-physical co-synthesis algorithm in-clude a CPS functional model CPS and a componentlibrary L including the existing models Comp of thephysical-components/sensors/actuators, pre-developed archi-tectures Arch, and the cyber-centric communication protocolsComm. The output of the cyber-physical co-synthesis algo-rithm is a set of architecture models AMset. The synthesisalgorithm (see Algorithm 1) consists of two steps. First, theSynthesizeBlocks step (see Algorithm 2) searches in the Lto find all the possible Comp which satisfy the functions

described in the given CPS. Second, the SynthesizeFlowsstep (see Algorithm 3) maps all flows in the CPS to thesensor/actuator components in the L. After these two stepsare completed, the algorithm evaluates the costs of all thesynthesized AM ∈ AMset from different perspectives basedon the cost functions introduced in Section III-D. Any AMviolating the given requirements R is excluded from thesynthesized architecture models. The synthesis steps iterateuntil all the candidate mappings are found. If there exists nopossible mapping (the returned AMset = ∅), it means that theCPS functional model is not synthesizable and the designermay update the CPS based on the synthesized CostAM .

Algorithm 1: Cyber-physical co-synthesis algorithm.Input: A CPS functional model:

CPS = {C,P,E,A,LC,LP,LE,LA}Input: Requirements: R = {req1, req2, ..., reqn}Input: Component Library: LOutput: A set of architecture models: AMset

1 SynthesizeBlocks(CPS, AMset) SynthesizeFlows(CPS, AMset)2 foreach Cost perspective & (AM ∈ AMset) do3 CostAM

pes = fpes(C)

4 if CostAMpes can’t satisfy R then

5 AMset = AMset/AM

Algorithm 2: SynthesizeBlocks(CPS, AMset) step.1 Variable: AMtemp, CBehavior

2 AMset = ∅3 foreach A ∈ CPS do4 AMtemp = ∅5 foreach Arch ∈ L do6 if (Arch ∈ L) matches (L(A) ∈ CPS) then7 AMtemp = AMtemp ∪Arch8 else9 Break

10 AMset = AMset ×AMtemp

11 foreach P ∈ CPS do12 AMtemp = ∅13 foreach Comp ∈ L do14 if Comp(CONS) satisfy (L(P ) ∈ CPS) then15 AMtemp = AMtemp ∪ Comp16 else17 Break

18 AMset = AMset ×AMtemp

19 foreach C ∈ CPS do20 AMtemp = ∅21 Find P ∈ CPS controlled by C22 foreach (Comp ∈ L) mapped to P do23 CBehavior=SynCtrlBehav(L(C), Comp)24 foreach Comp ∈ L do25 if Comp(CONS) satisfy CBehavior then26 AMtemp = AMtemp ∪ Comp27 else28 Break

29 AMset = AMset ×AMtemp

30 return TRUE

Given the CPS functional model CPS as the input, theAlgorithm 2 traverses through all the blocks in CPS tofind appropriate Comp ∈ L or Arch ∈ L which satisfythe functions/specifications. Lines 3-10 find all the possible

IEEE SYSTEMS JOURNAL, VOL. XX, NO. X, MONTH 2015 7

mappings from A ∈ CPS to Arch ∈ L. Then, lines 11-18 find all Comp ∈ L mapped from P ∈ CPS. Noticethat line 14 validates whether the constraints of a componentComp(CONS) (such as the input/output types, the functionsachieved by the component, etc.) satisfy the physical functionsdescribed in L(P ) ∈ CPS. Similarly, lines 19-29 find allComp ∈ L those satisfy the control specifications describedin L(C) ∈ CPS. However, compared to the mapping ofthe physical processes, the control specifications [37] can-not be mapped directly to the constraints of componentsComp(CONS). Therefore, the mapping of C ∈ CPS isdivided into two sub-steps: 1) Line 23 calls the SynCtrlBehavfunction to synthesize C ∈ CPS into a control behaviorCbehavior with the help of the behavior description of thephysical components (e.g. mathematical models) and 2) Lines24-28 check whether C ∈ L satisfy the Cbehavior (such asthe number of input/output signals, the complexity of thecontrol algorithm, etc.). Finally, all the possible mappingsare aggregated onto AMset. Notice that the implementationof the function SynCtrlBehav is not in the scope of thispaper, existing work in [37] and [28] have provided thepossible methodologies of automatically synthesizing controlspecifications into control behaviors described in LTL.

Algorithm 3: SynthesizeFlows(CPS, AMset) step.1 Variable: BS , BT , Etemp1, Etemp2, AMtemp

2 foreach E ∈ CPS do3 BS=Source block of E4 BT =Termination block of E5 foreach ((Comps ∈ L) mapped to (BS in AMset)) &&

((Compt ∈ L) mapped to (BT in AMset)) do6 Archtemp1 = ∅, Archtemp2 = ∅7 if (Comps & Compt) in the same domain then8 foreach Comm ∈ L in the same domain do9 Set Etemp1 as a connection from Comps to

Compt10 L(Etemp1) = Comm11 AMtemp=AMtemp ∪ EArchtemp1

12 else13 foreach Comm ∈ L do14 if CONS(Comp) match the domains of

Comps → Compt then15 foreach Comm ∈ L in the domain of Comps

do16 Set Etemp1 as a connection from Comps

to Comp17 L(Etemp1) = Comm

18 foreach Comm ∈ L in the domain of Comptdo

19 Set Etemp2 as a connection from Compto Compt

20 L(Etemp2) = Comm

21 AMtemp=AMtemp ∪ Etemp1 ∪ Etemp2 ∪Comp

22 AMset = AMset ×AMtemp

23 return TRUE

Algorithm 3 traverses E ∈ CPS to satisfy all the designrequirements. Lines 3-5 find all the components for the sourceand destination block of E ∈ CPS. Lines 7-11 check whetherthe flow is connecting two components that are synthesized inthe same domain. If the condition is satisfied, a single connec-

tion is constructed. Notice that if the domain is a cyber domain,Lines 8-10 will find all the possible communication protocolsfor this connection. Lines 13-21 handle the scenario whenthe source and the destination of the flow falls onto differentdomains. In such a scenario, a proper C ∈ L is chosen toconnect these two domains in Lines 13-14. Our explorationshows that this step may generate additional sensors andactuators for connecting components from different domains.Finally, Line 22 aggregates all the possible mappings.

In Algorithm 2, the loop at Lines 3-10 has a complexity ofO(n2), the loop at Lines 11-18 has a complexity of O(n2),the loop at Lines 19-29 has a complexity of O(n3). Thus, thetime complexity of Algorithm 2 is O(n3). In Algorithm 3,each of the inner loops at Lines 8-11, Lines 15-17, and Lines18-20 has a complexity of O(n). Thus, the loop at Lines 13-21has a complexity of O(n2) and the outer loop at Lines 2-22has a complexity of O(n3). As a result, the time complexityof Algorithm 3 is O(n3). In Algorithm 1, the loop at Lines3-6 has a complexity of O(n2). Therefore, the complexity ofAlgorithm 1 is also O(n3 + n3 + n2) = O(n3), which issolvable in polynomial time.

IV. EXPERIMENTS AND CASE-STUDY ANALYSIS

In order to demonstrate the capability of our co-designmethodology in the automotive design, we present a case-study of designing part of an automotive system. The designedCPS functional model shown in Figure 5 is a partial viewon several subsystems of an automotive. We assume that forthis use case, four architecture blocks in Figure 5, Driver,Engine system, Transmission system, and Wheel already havethe corresponding architectures in the library. Therefore, theseblocks may be directly synthesized into existing architectures.However, the Steering system and Braking system do not havethe corresponding architectures, therefore we have describedthese two subsystems in details using the CPS functionalmodel. In this case-study, we use general energy type *E indesigning the CPS functional model, therefore, this leaves thetask of multi-domain DSE to the synthesis algorithm.

Convert *E

to RME

Convert

controller

*E

RME

Convert

RME to TME

Convert

Human E.

RME TME

DriverTransmission

system

Engine

system

Wheel

RME

TME

HE

Steering system

Store *E

Store *E

Convert

controller*E

Convert *E

to TME

Convert

Human E.TME

HE

Braking system

Fig. 5. The CPS functional model for parts of an automotive.

A. Analysis of the Synthesis Process

After synthesizing the CPS functional model, we obtain fivedifferent architectures in this case-study. Notice that basedon the available architectures from the automotive industry,we may get more synthesized architectures from this CPSfunctional model. However, in this paper we only demonstrate

IEEE SYSTEMS JOURNAL, VOL. XX, NO. X, MONTH 2015 8

five of those to verify our proposed methodology. The firstarchitecture uses a purely traditional physical domain compo-nents; the second and third architectures use E/E componentsfor braking and steering only; the fourth and fifth use thegreatest number of E/E components for driving with varyingtypes of different ECUs (single-core and multi-core). Wedenote these five architectures as: Traditional/TRAD, Brake-By-Wire/BBW, Steer-By-Wire/SBW, Drive-By-Wire/DBW, andDBW (multi-core). Table I summarizes comparison of thenumber of required components among these architectures.

TABLE ICOMPARISON OF FIVE SYNTHESIZED ARCHITECTURES

Compsnumbers

ECUsnumbers

Sensorsnumbers

Actuatorsnumbers

TRAD 20 0 0 6BBW 22 3 5 6SBW 21 1 2 5DBW 23 4 7 5DBW

(multi-core) 20 1 7 5

Our synthesis algorithm uses the parameters defined manu-ally in the library (some components used for our experimentsare shown in Table II). These parameters are relevant for thecost function calculation and are implementation dependent5.Costs are calculated during the synthesis stage as presented inSection III-E. Our synthesis algorithm shows that from perfor-mance and power consumption perspectives, DBW and DBW(multi-core) – with the greatest number of E/E components –represent the least expensive architectures, while the TRAD –without any E/E component – represents the most expensivearchitecture (3X more performance cost and 1.8X more powerconsumption costs compared to DBW and DBW (multi-core)).However, from reliability and robustness perspectives, DBWhas 2.95X more the cost of the TRAD. Table III shows someof the cost calculation results using our synthesis algorithm.These results indicate that E/E components represent a trade-off between performance, power, and reliability. Notice thatcompared to DBW, DBW (multi-core) architecture maintain thesame performance and power consumption while providingbetter reliability and robustness.

TABLE IIEXAMPLE LIST OF THE COMPONENTS IN THE COMPONENT LIBRARY

treaction(seconds)

Pconsum

(watts)MTBFnorm

(hours)MTBFharsh

(hours)ECU <0.1 <100 1e+05 1e+04

DC Motor <0.1 0-2500 1e+06 1e+06Pump <0.1 3000 1e+06 1e+06Pipe 0.2 N/A 1e+06 1e+06

Gears 0.1 N/A 1e+06 1e+06

With the help of these cost calculations, the designer mayobtain the optimized architecture according to the given re-quirements. For example, given a requirement that the perfor-mance cost should be less than 0.3s (for the purpose of betterdriving experience) and the reliability cost should be less than

5Our parameters are representative of generic components.

TABLE IIICOST RESULTS FOR VARIOUS AUTOMOTIVE ARCHITECTURES

Costperf(seconds)

CostpowerCostrel

(errors/hour)Costrobst

TRAD 0.3 51.4% 2e-05 1BBW <0.3 60% 4.9e-05 6.5SBW 0.1 90% 3e-05 4DBW <0.1 90% 5.9e-05 7.1DBW

(multi-core) <0.1 90% 3e-05 4

4e − 05 errors/hour, SBW and DBW (multi-core) are thearchitectures those are satisfying these requirements.

In this case-study, we notice that the differences betweentwo architectures, DBW and DBW (multi-core) lies in the cyberdomain architecture. Figure 6 presents part of the architecturesof the braking system for both DBW and DBW (multi-core)architectures. The convert controller (the control specificationblock in the braking system in Figure 5) has the specificationsdescribed using LTL shown in Figure 6. The specification hasthree terms that may be synthesized onto three separate controltasks: Electronic Brakingforce Distribution (EBD), ElectronicStability Programme (ESP), and Anti-Lock Braking System(ABS). In DBW architecture, three single ECUs are deployedfor each of the control tasks, whereas in DBW (multi-core),all three tasks are implemented in a single multi-core ECU.The cost calculation results clearly show that DBW has 1.97Xmore cost on reliability and 1.78X more cost on robustnessperspectives compared to DBW (multi-core). However, boththe two architectures have the same performance and powerefficiency. Although in this case-study, we do not consider theother costs such as the price, weight those may be greatlyeffected by the cyber architecture due to the wiring problemand different sensor connections, our results still show thatthe integration of ECUs will bring greater benefit for theautomotive design [27].

Brake

pedal

Force

Sensor

EBD ECU

ESP ECU

ABS ECU

Rear Right

Caliper

Rear Left

Caliper

Driver

Front Left

Caliper

Front Right

Caliper

Other

Sensors

DC

Motor

DC

Motor

DC

Motor

DC

Motor

Torque

Sensors

Brake

pedal

Force

Sensor

Multi-core

ECU

Rear Right

Caliper

Rear Left

Caliper

Driver

Front Left

Caliper

Front Right

Caliper

Other

Sensors

DC

Motor

DC

Motor

DC

Motor

DC

Motor

Torque

Sensors

1) □((The driver brakes) ˄ (Wheel speeds available) → ⃝ (Adjust the force

distribution on wheels) → □(Highest brake efficiency))

2) □((The driver brakes) → □ (The vehicle body is stable))

3) □((The driver brakes) → □¬ (The tyres lock))

Convert Controller Specifications

(a) Three single-core ECUs (b) One multi-core ECUs

Fig. 6. Comparison of the cyber domain architectures between DBW andDBW (multi-core).

B. Simulation and Validation

To validate the calculated costs of performance and powerconsumption, we consider a corner-turning scenario. The input

IEEE SYSTEMS JOURNAL, VOL. XX, NO. X, MONTH 2015 9

signal is shown in Figure 7, where the driver first pressesthe braking pedal to slow down the automotive (the forceof pressing the braking pedal is the input signal from time0−1.5 Seconds) and then turns the steering wheel (the anglesof the steering wheel is the input signal from 1.5−3 Seconds)to turn the automotive during a corner-turning scenario. Wehave implemented all these four architectures in the state-of-the-art multi-domain simulation platform Amesim [1]. Thesimulation results on performance and energy consumptionshown in Figure 8 and 9 validate the cost calculation per-formed by our algorithm. For example, according to the costcalculation in the synthesis stage, the architectures TRAD andBBW use the hydraulic pipe for constructing the steeringsystem and thus have a reaction delay of 0.2− 0.3 Seconds,which matches the simulation result in Figure 8.

0

100

200

300

400

0 0.5 1 1.5

Forc

e (

New

ton

s)

Driving time (Seconds)

0

20

40

60

1.5 2 2.5 3

An

gle

(D

egr

ee

s)

Driving time (Seconds)

Fig. 7. The input signals of a corner-turning scenario.

0

1000

2000

3000

4000

5000

6000

7000

0 0.25 0.5 0.75 1 1.25 1.5Ap

plie

d f

orc

e (

Net

wo

ns)

Driving time (Seconds)

TRAD

BBW

SBW

DBW

0

100

200

300

400

500

600

1.5 1.75 2 2.25 2.5 2.75 3Ap

plie

d f

orc

e (

New

ton

s)

Driving time (Seconds)

TRAD

BBW

SBW

DBW

Fig. 8. Performance comparison for various automotive architectures.

0

500

1000

1500

2000

2500

3000

3500

4000

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 2.4 2.6 2.8 3

Po

we

r co

nsu

mp

tio

n (

Wat

ts)

Driving time (Seconds)

TRAD power consumption

BBW power consumption

SBW power consumption

DBW power consumption

Fig. 9. Power consumption comparison for various automotive architectures.

We have also conducted a tradeoff analysis between thereliability costs and the performance costs from the simulationresults. The results presented in Figure 10 have validated ouranalysis in Table III during the synthesis process.

Although this case-study demonstrates the effectiveness ofthe proposed co-design methodology, some existing limitationsneed to be addressed in our future work. We currently have alimited number of components in the library. Therefore, addingmore components could help the proposed methodology tohandle more design tasks. Moreover, our CPS functionalmodel description is currently limited to only Functional Basis

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.00E+00

1.00E-05

2.00E-05

3.00E-05

4.00E-05

5.00E-05

6.00E-05

7.00E-05

TRAD BBW SBW DBW DBW(multi-core)

Pe

rfo

rman

ce C

ost

(se

con

ds)

Re

liab

ility

Co

st (

err

ors

/ho

ur) Reliability Cost Performance Cost

Fig. 10. Tradeoff analysis between reliability and performance costs.

language and LTL. Therefore, other functional modeling lan-guages and tools for both cyber domain and physical domaindescription need to be evaluated in future.

V. RELATED WORK

Efficient DSE in the semiconductor industry is a major areaof research. Various Hardware/Software co-design methodolo-gies and design automation tools [14, 17] have been proposedfor identifying the optimized architecture for the given systemobjectives. Moreover, the co-design methodology has alsobeen shown to be applicable for the multi-domain physicalsystems consisting of various physical domains such as elec-trical, mechanical, hydraulic, pneumatics, etc. [31]. In recentyears, with the increasing interactions between the electronic-domain (control/computation/communication) and the physicaldomain, DSE across software-integrated multi-domains (con-tinuous and discrete dynamics) has been considered as thegrand research challenge for designing the complex CPS [32].

Although multi-domain design is addressed in the existingCPS design methods, most of them are limited in targetingthe cyber parts or the physical parts separately. Compared toour work, there exists no method that is capable of providinga unified abstraction of the system that could explore thesoftware-integrated multi-domain design space. Descriptionlanguage such as Architecture Analysis & Design Language(AADL) described in [11] is limited in describing the architec-tures for software. Modeling languages such as Modelica [34]or Simscape [23] are mainly proposed for modeling themulti-domain physical components. The LTL specificationsproposed in [37] is specialized for control specification. Forexample, Pessoa [22] is a tool capable of synthesizing theembedded controllers from the control specifications. Workin [5, 6, 7, 35, 36] including our prior work provide meth-ods for synthesize functional models into simulation models;however they are mainly focused on physical components.Our prior work in [7, 35] explore the existing architecturesfor synthesizing functional models into simulation models;however, they are limited on physical architectures only.Moreover, functional modeling technique shown in our priorwork in [7, 35] is not capable of partitioning control and(multi-)physics explicitly at the functional-level in order tosupport a fine-grained cyber-physical co-design. Work in [2]have demonstrated the importance of multi-domain design fora CPS in the system-level. However, [2] does not provide a

IEEE SYSTEMS JOURNAL, VOL. XX, NO. X, MONTH 2015 10

solution for automatically generating architecture models ordetailed designs from the functional models.

Furthermore, targeting multi-domain CPS designs, Model-Based Designs (MBD) [10], Concurrent Engineering (CE) [33]are proposed for the purpose of reducing design time and ex-ploring the design space. However, all these works mainly relyon the knowledge of the domain experts to make the decisionsduring the modeling stages. Therefore, this limits the DSEcompared to our domain-independent functional modelingmethodology. Another methodology in [24] named Multi-ViewModel (MVM) is proposed for designing multi-view systems.Compared to our high-level synthesis methodology, this workfocuses on describing the relationship between multi-views(e.g. control view, software view, architecture view etc.) ofa design.

Besides the DSE for architectures, scheduling of communi-cation and computation is another major research area in theautomotive CPS co-design. Works presented in [15, 16, 29, 38]provide various methodologies for control-communication co-design of the CPS. In this paper, we focused on presenting thesynthesis stage and DSE of various automotive architectures.Although we focus on presenting the synthesis stage and DSEof various automotive architectures, these existing schedulingworks may help our method to generate more realistic simu-lation models after the architecture is decided.

VI. CONCLUSION

This paper proposes a novel functional-level co-designmethodology for the automotive CPS. The marriage of systemsengineering principles with high-level synthesis techniquesfrom design automation area results in a new co-designmethodology capable of helping the DSE and validationof multi-domain automotive architectures. A new modelingtechnique for the CPS, referred to as the CPS functionalmodel, is presented to capture the high level functions andspecifications of (multi-)physics and controls. Starting fromthe functional model, a synthesis algorithm is presented togenerate the detailed architectures and associated costs ondifferent perspectives for the automotive CPS. Furthermore,the architectures can be translated to simulation models usingvarious executable components from multi-domain simulationplatforms. Using the proposed methodology, an automotivecase-study has been demonstrated to explore five alternativearchitectures. Our synthesis algorithm shows that: TRAD has3X more the performance cost and 1.8X more the powerconsumption costs compared to DBW, while from the reliabil-ity and robustness perspectives, DBW has 2.95X more costscompared to TRAD. Moreover, our co-design methodology andthe cost analysis have been validated using the state-of-the-artmulti-domain automotive simulation platform.

REFERENCES[1] “Amesim Platform”. http://www.lmsintl.com/LMS-Imagine-Lab-Amesim/.[2] A. Alvarez Cabrera, K. Woestenenk, and T. Tomiyama. “An architecture model

to support cooperative design for mechatronic products: A control design case”.Mechatronics, pages 534–547, 2011.

[3] S. P. Boyd, L. El Ghaoui, E. Feron, and V. Balakrishnan. “Linear matrix inequalitiesin system and control theory”. SIAM, 1994.

[4] M. Broy, S. Chakraborty, S. Ramesh, M. Satpathy, S. Resmerita, and W. Pree.“Cross-layer analysis, testing and verification of automotive control software”. In

Proceedings of the International Conference on Embedded Software, (EMSOFT),pages 263–272, 2011.

[5] A. Canedo, M. A. A. Faruque, and J. H. Richter. “Multi-disciplinary integrateddesign automation tool for automotive cyber-physical systems”. In Proceedingsof the Conference on Design, Automation and Test in Europe (DATE), page 315,2014.

[6] A. Canedo, E. Schwarzenbach, and M. A. A. Faruque. “Context-sensitive Synthesisof Executable Functional Models of Cyber-physical Systems”. In Proceedings ofthe ACM/IEEE 4th International Conference on Cyber-Physical Systems (ICCPS),pages 99–108, 2013.

[7] A. Canedo, J. Wan, and M. A. A. Faruque. “Functional Modeling Compiler forSystem-Level Design of Automotive Cyber-Physical Systems”. In Proceedingsof the ACM/IEEE International Conference on Computer-Aided Design (ICCAD),2014.

[8] R. N. Charette. “This car runs on code”. IEEE Spectrum, page 3, 2009.[9] D. A. Cooprider. “Automotive Embedded Systems Tutorial”. Proceedings of the

51st Annual Design Automation Conference (DAC), pages 1–23, 2014.[10] P. Derler, E. A. Lee, and A. S. Vincentelli. “Modeling cyber–physical systems”.

Proceedings of the IEEE, pages 13–28, 2012.[11] P. H. Feiler, D. P. Gluch, and J. J. Hudak. “The architecture analysis & design

language (AADL): An introduction”. DTIC Document, 2006.[12] G. Fortney. “Model based systems engineering using validated executable specifi-

cations as an enabler for cost and risk reduction”. Proceedings of the 2014 GroundVehicle Systems Engineering and Technology Symposium (GVSETS), 2014.

[13] D. Frede, M. Khodabakhshian, and D. Malmquist. “A state-of-the-art survey onvehicular mechatronics focusing on by-wire systems”. KTH Royal Institute ofTechnology, 2010.

[14] J. Gong, D. D. Gajski, and S. Bakshi. “Model refinement for hardware-softwarecodesign”. ACM Transactions on Design Automation of Electronic Systems(TODAES), pages 22–41, 1997.

[15] D. Goswami, M. Lukasiewycz, M. Kauer, S. Steinhorst, A. Masrur, S. Chakraborty,and S. Ramesh. “Model-based development and verification of control software forelectric vehicles”. Proceedings of the 50th Annual Design Automation Conference(DAC), page 96, 2013.

[16] D. Goswami, R. Schneider, and S. Chakraborty. “Co-design of cyber-physicalsystems via controllers with flexible delay constraints”. Proceedings of the 16thAsia and South Pacific Design Automation Conference, pages 225–230, 2011.

[17] R. K. Gupta and G. De Micheli. “Hardware-software cosynthesis for digitalsystems”. IEEE Design & Test of Computers, pages 29–41, 1993.

[18] J. Hirtz, R. B. Stone, D. A. McAdams, S. Szykman, and K. L. Wood. “A functionalbasis for engineering design: reconciling and evolving previous efforts”. Researchin Engineering Design, pages 65–82, 2002.

[19] J.-H. Kim and J.-B. Song. “Control logic for an electric power steering systemusing assist motor”. Mechatronics, pages 447–459, 2002.

[20] H. Komoto and T. Tomiyama. “A framework for computer-aided conceptual designand its application to system architecting of mechatronics products”. Computer-Aided Design, pages 931–946, 2012.

[21] G. Leen and D. Heffernan. “Expanding automotive electronic systems”. Computer,pages 88–93, 2002.

[22] M. Mazo Jr, A. Davitian, and P. Tabuada. “Pessoa: A tool for embedded controllersynthesis”. Computer Aided Verification, pages 566–569, 2010.

[23] S. Miller and J. Wendlandt. “Real-Time Simulation of Physical Systems UsingSimscape”. MATLAB News and Notes, 2010.

[24] M. Persson, M. Torngren, A. Qamar, J. Westman, M. Biehl, S. Tripakis,H. Vangheluwe, and J. Denil. “A characterization of integrated multi-view modelingin the context of embedded and cyber-physical systems”. Proceedings of theEleventh ACM International Conference on Embedded Software, page 10, 2013.

[25] A. Pretschner, M. Broy, I. H. Kruger, and T. Stauner. “Software engineering forautomotive systems: A roadmap”. Future of Software Engineering, pages 55–71,2007.

[26] S. Ramesh and A. Gadkari. “Rigorous model-based design & verification flowfor in-vehicle software”. Proceedings of the 48th Annual Design AutomationConference (DAC), pages 13–16, 2011.

[27] K. Richter, M. Jersak, and R. Ernst. “Learning early-stage platform dimensioningfrom late-stage timing verification”. In Proceedings of the Conference on Design,Automation and Test in Europe (DATE), pages 851–857, 2009.

[28] M. Rungger, M. Mazo Jr, and P. Tabuada. “Specification-guided controller synthesisfor linear systems and safe linear-time temporal logic”. Proceedings of the 16thinternational conference on Hybrid systems: computation and control, pages 333–342, 2013.

[29] F. Sagstetter, S. Andalam, P. Waszecki, M. Lukasiewycz, H. Stahle, S. Chakraborty,and A. Knoll. “Schedule Integration Framework for Time-Triggered AutomotiveArchitectures”. In Proceedings of the 51st Annual Design Automation Conference(DAC), pages 1–6, 2014.

[30] M. Senga. “Modeling and analysis of power steering systems”. MassachusettsInstitute of Technology, 1995.

[31] R. Sinha, C. J. Paredis, V.-C. Liang, and P. K. Khosla. “Modeling and simulationmethods for design of engineering systems”. Journal of Computing and InformationScience in Engineering, pages 84–91, 2001.

[32] D. Stuart, R. Mattikalli, D. DeLaurentis, and J. Shah. “META II”. 2011.[33] K. Thramboulidis. “Model-integrated mechatronics-toward a new paradigm in

the development of manufacturing systems”. IEEE Transactions on IndustrialInformatics, pages 54–61, 2005.

[34] M. Tiller. “Introduction to physical modeling with Modelica”. Springer, 2001.[35] J. Wan, A. Canedo, and M. A. A. Faruque. “Functional Model-based Design

Methodology for Automotive Cyber-Physical Systems”. IEEE Systems Journal

IEEE SYSTEMS JOURNAL, VOL. XX, NO. X, MONTH 2015 11

(ISJ), 2014.

conference on Hybrid systems: computation and control, pages 101–110, 2010.[38] H. Zeng, M. Di Natale, A. Ghosal, and A. Sangiovanni-Vincentelli. “Schedule

optimization of time-triggered systems communicating over the FlexRay staticsegment”. IEEE Transactions on Industrial Informatics, pages 1–17, 2011.

Jiang Wan received the the Bachelor’s Degree ofMicroelectronics from Shanghai JiaoTong Univer-sity in 2008 . Currently, he is pursuing the Ph.D.degree in the department of Electrical Engineeringand Computer Sciences at University of CaliforniaIrvine. His current research interests include de-sign automation methodology for automotive cyber-physical systems, multi/many-core systems and reli-ability. Jiang Wan is an IEEE student member.

Arquimedes Canedo is a Principal Key ExpertScientist at Siemens Corporation, Corporate Tech-nology in Princeton, USA. His areas of interest aremulti-domain simulation, multi-scale modeling, andconcept design of cyber-physical systems.

Mohammad A. Al Faruque is currently with Uni-versity of California Irvine (UCI), where he is atenure track assistant professor and directing theEmulex Career Development Chair and the Ad-vanced Integrated Cyber-Physical Systems (AICPS)lab. He is also affiliated with the Center for Embed-ded and Cyber-Physical Systems (CECS) at UCI.Before joining at UCI, he was with Siemens Cor-porate Research and Technology at Princeton, NJ asa research scientist. His current research is focusedon system-level design of embedded systems and/or

Cyber-Physical Systems (CPS) with special interest on complex software-defined systems modeling, real-time scheduling algorithms, multi-core sys-tems, dependable CPS systems, etc. Mohammad Al Faruque is an IEEE andan ACM member.

[36] K. Woestenenk, H. Tragter, G. M. Bonnema, A. A. A. Cabrera, and T. Tomiyama.“Multi domain design: integration and reuse”. ASME 2010 International DesignEngineering Technical Conferences and Computers and Information in EngineeringConference, pages 519–528, 2010.

[37] T. Wongpiromsarn, U. Topcu, and R. M. Murray. “Receding horizon controlfor temporal logic specifications”. Proceedings of the 13th ACM international