Model-Based Control Design and Integration of ......tural replica of the Matlab/Simulink model in the ESMoL modelingenvironment.ThereplicaoftheMatlab/Simulink model is represented

Hindawi Publishing CorporationJournal of Control Science and EngineeringVolume 2013 Article ID 678016 15 pageshttpdxdoiorg1011552013678016

Research ArticleModel-Based Control Design and Integration ofCyberphysical Systems An Adaptive Cruise Control Case Study

Emeka Eyisi Zhenkai Zhang Xenofon Koutsoukos Joseph PorterGabor Karsai and Janos Sztipanovits

Institute for Software Integrated Systems (ISIS) Vanderbilt University Nashville TN 37212 USA

Correspondence should be addressed to Emeka Eyisi emekaeyisivanderbiltedu

Received 7 September 2012 Accepted 18 December 2012

Academic Editor Sabri Cetinkunt

Copyright copy 2013 Emeka Eyisi et al This is an open access article distributed under the Creative Commons Attribution Licensewhich permits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

The systematic design of automotive control applications is a challenging problem due to lack of understanding of the complex andtight interactions that often manifest during the integration of components from the control design phase with the componentsfrom software generation and deployment on actual platformnetwork In order to address this challenge we present a systematicmethodology and a toolchain usingwell-definedmodels to integrate components fromvarious design phases with specific emphasison restricting the complex interactions that manifest during integration such as timing deployment and quantization We presentan experimental platform for the evaluation and testing of the design process The approach is applied to the development of anadaptive cruise control and we present experimental results that demonstrate the efficacy of the approach

1 Introduction

Cyberphysical systems (CPS) represent a class of complexsystems characterized by the tight interactions between thephysical dynamics computational dynamics and communi-cation networks Automotive systems are classical examplesof CPS and have recently been gaining increased attentiondue to the emerging challenges in their design Currentautomotive systems employ up to 100 electronic controlunits (ECUs) exchanging more than 2500 signals over upto 5 different bus systems [1 2] These ECUs control andmonitormany subsystems of a vehicle such as chassis controlvehicle stability and engine control The development ofcontrol software has become one of the greatest challenges inthe automotive domain due to the increasing complexity ofautomotive systems as well as the increasing roles of controlcomputing and communication [3ndash6]

The increased pressure to integrate as much functionalityon as few ECUs as possible the persistent effort for low pro-duction costs and tight time-to-market constraints furthercomplicate the development of automotive software controlsystems Due to these challenges there is a dire need for

a reliable and efficient approach for control software develop-ment and integration Amajor problem in the current state ofart is that most issues with deployed control applications aretypically discovered in the final phases of the developmentcycle and at these later phases correcting the issues is veryexpensive as it involves the modification of specificationsrequirements and design Another issue is the lack of realisticexperimental platforms for integrating and testing developedcontrol software prior to deployment

Systematic design and analysis of automotive controlsoftware early in the development cycle is very crucialThe model-driven development approach has been foundto be very beneficial in addressing these issues [7] How-ever the lack of a sound approach for the integration ofcomponents from the control design phase with the compo-nents from software generation and deployment on actualplatformnetwork makes the model-driven approach verychallenging because the tight interactions between the designphases often manifest during integration The current state-of-the-art often resorts to ad hoc methods with the goal ofldquomaking the systemworkrdquoThese ad hocmethods are becom-ing unpractical as the complexity of the system increases

2 Journal of Control Science and Engineering

In this paper we present a step towards addressing thechallenges in the design and integration of components fromcontrol design with components from software generationand deployment on actual platformnetwork We present asystematic methodology and a toolchain to integrate controldesign and scheduling in the development of automotivecontrol applications with specific emphasis on restrictingthe interactions that manifest during integration such astiming deployment and quantization Our design processutilizes a model-based toolchain Embedded SystemsModel-ing Language (ESMoL) [8] ESMoL designed in the GenericModeling Environment (GME) [9] is a single multiaspectembedded software design environment which streamlinescontrol design with software modeling code generation anddeployment on platformnetwork filling the very impor-tant details between the design phases promoting a high-confidence software development process

In order to evaluate our software development processand toolchain we employ an experimental platform based onthe time-triggered paradigm that enables the deployment andtesting of automotive control applicationsThe time-triggeredparadigm is used to address the complexity and composabil-ity challenges by precisely defining the interfaces betweencomponents in order to provide predictability [10] Also ourchoice of a time-triggered paradigm falls in line with theincreased ongoing efforts towards the standardization of in-car communication networks such as FlexRay and Time-Triggered Ethernet (TTEthernet or TTE) with the overallgoal of guaranteeing highly reliable deterministic and fault-tolerant system performance [11]

The software development process and toolchain togetherwith the experimental platform efficiently connect all thephases of development of automotive control applicationsessentially going from control design using MatlabSimulinkto deployment and hardware-in-the-loop simulations Inorder to demonstrate our approach we apply the proposedprocess to the development of an adaptive cruise control(ACC)The adaptive cruise control (ACC) system is an activesafety and driver-assistance vehicle feature that automaticallycontrols a vehiclersquos longitudinal velocity in a dynamic trafficenvironment ACC enables an ACC-equipped vehicle tofollow a leading forward moving vehicle while maintaininga desired distance from the leading vehicle as determined bythe vehiclersquos velocity and a specified time gap or headwayWe present experimental results from the hardware-in-the-loop simulations of the designed ACC on the experimentalplatform

This paper is organized as follows The related workis presented in Section 2 In Section 3 we describe ourview of CPS design and integration and we formulate thespecific problem considered in this paper We present theproposed systematic methodology for model-based controldesign and integration in Section 4 Section 5 presents thesystem architecture for the experimental platform Section 6describes the control design of the adaptive cruise controlSection 7 describes the software design process for theadaptive cruise control Section 8 presents an experimentalevaluation of our proposed approach using the adaptive

cruise control case study Finally Section 9 provides a briefdiscussion and concludes the paper

2 Related Work

Model-based software development approach as well as test-beds for testing automotive control systems architecture is avery active research area There is an increasing amount ofwork in this area attempting to address various cross-layerchallenges [12] In [13] an automotive testbed for electroniccontroller unit testing and verification was presented Thepresented platform provides many advantages for testingECUs and is complementary to our workThe authors in [14]present a software-based implementation and verificationscheme for a FlexRay-based automotive network The mainfocus of the paper is on verifying timing in control signalsand the network and providing a basis for detecting and diag-nosing network faults In [15] the authors used a techniquecalled Instrumentation-Based Verification (IBV) to designautomated tests in order to check whether models developedin MatlabSimulink satisfy specified requirements while thework addresses an important issue of verifying requirementswith control design it does not go further into the actualsoftware deployment and evaluation on a test platform

The design of the adaptive cruise control (ACC) hasbeen extensively studied and there are numerous designtechniques for deriving the corresponding control laws Someof the most common approaches are sliding-mode designtechniques [16 17] optimal control techniques [18 19] fuzzylogic [20] neural networks and proportional derivative (PD)type control law [21 22] In this work our main focus in thecase study is on the design flow from the high level design ofa vehicle control system such as the ACC using model-basedtools such as MatlabSimulink to the actual deployment andtesting on an automotive testbed capable of mimicking realworld scenarios In [23] the authors describe a model-basedapproach for the modeling designdere and implementationof an intelligent cruise control In contrast to their approachour development approach provides a simpler graphical lan-guage that clearly defines the integration of the control soft-ware In addition we adopt the time-triggered architecture[10] which essentially ensures predictability determinismand guaranteed latencies hence allowing for a certain levelof decoupling in system design The work in [24] describes aFlexRay-based distributed networked system for automotiveapplications mainly focusing on the challenges in regardsto the paradigm shift from the Controller-Area-Network-(CAN-) based even-triggered communication technologiesto the introduction of time-triggered communication schemewhile assuming an existing software environment

Our work differs from the existing works due to the factthat we consider an end-to-end design flow in the devel-opment of control software with well-defined componentsthat are necessary for the efficient and reliable integrationof design layers of an automotive CPS By clearly definingthese components which include timing and deployment werestrict the possible interactions that can potentiallymake theoverall behavior of the system unpredictable

Journal of Control Science and Engineering 3

Computationalobject

Computationalobject

Computationalobject

Computationalobject

Computationalobject

Computationcommunication layer

Computationalplatform

Platform layer

Physical object Physical object

Communication platform

Implementation

Cyberphysical object

Physical layer

Cyberphysical object

Physical object

Computational interaction Physical interaction

Computational platform

Implementation

Abstr

actio

n

Refin

emen

t

Figure 1 Design flow in CPS design layers [25]

3 Problem Formulation

Figure 1 shows the three fundamental design layers of CPSsuch as an automotive vehicle [25]

(1) The physical layer represents physical componentsand their interactions The behavior of the physicalcomponents is governed by physical laws and is typ-ically described in continuous (physical) time usingfor example ordinary differential equations (ODEs)Physical objects are interconnected by physical com-ponents (eg steeringwheel) or cyberphysical objects(eg steer by wire)

(2) The platform layer represents the hardware side ofCPS and includes the network architecture and com-putation platform that interact with the physicalcomponents through sensors and actuators Whileexecuting the software components on processorsand transferring data on communication links theirabstract behavior is ldquotranslatedrdquo into physical behav-ior

(3) The computationcommunication layer represents thesoftware components with behavior expressed in log-ical time Interconnections aremodeled using various

Models of Computations (MoCs) [26] Software com-ponents are connected using an inputoutput modelwith an implied notion of causality

In view of this CPS architecture for an automotiveapplication the vehicle chassis together with the enginetransmission brakes and tires cyberphysical objects (egsteer by wire) and the initial controller design comprise thephysical layer The electronic control units (ECUs) on whichthe control software applications are deployed together withthe communication network over which the ECUs send andreceive data comprise the platform layer

In this work we assume that the components of thephysical layer are specified by a given physical vehicledynamic model Also we assume that the platform layeris specified based on a given set of computational nodesand communication network The main research problemwe address is handling the complex interactions in thecomputationcommunication layer of automotive CPS whichmanifest due to the lack of a clear andwell-defined systematicintegration of control design and scheduling This probleminvolves the need for a ldquocorrect-by-constructionrdquo end-to-enddesign methodology for the modeling designing analysisdeployment and testing of automotive control applicationsIn order for such a development process to be beneficialit should be systematic and efficient Additionally such an

4 Journal of Control Science and Engineering

Control design (Simulink)

User-side language (ESMoL)

Design model aspects

Requirements

Softwarearchitecture Deployment

Behavior

Transformationof model

details

1

2 4 3

5

6

7 8

Hardwareplatform

Imports model structure

Intermediate language (ESMoL abstract)

Semantic model layers

Requirements (constraints)

Instances andparameters

Syntaxgeneration

Schedulability andtiming analysis

RequirementsDependencies

ResourcesComponent timing

Requirements

Other tools

DependenciesResources

Component timing

Model relations

Behavior

Releasetimes

Softwaregeneration

Target tools and languages

Figure 2 Automotive embedded control software design flow supported by the ESMoL language and modeling tools

approach will require an experimental platform that is ableto model realistic scenarios that can mimic real-world cases

4 Automotive Control SoftwareDesign Process

The proposed approach uses formal models and designconcepts integrated in the model-based tool chain ESMoLto restrict component interactions by specifying attributesin various refinements of a single design model of anapplication These refinements which include componentarchitecture deployment and timingexecutionmodels rep-resent different aspects of the system as the process pro-gresses towards implementation The combined informationexpressed in the aspects constitutes a suitable completemodelfor the actual deployment and implementation of the systemWe provide the design flow of the development process

41 Automotive Control SoftwareDesign Flow Figure 2 showsthe design flow for the proposed software development pro-cess The design process involves eight main steps numberedin a top-down manner starting from the first step whichinvolves the importation of a control design model intoESMoL to the eighth and final step of software generationas shown in Figure 2 The design steps are described as inFigure 2

411 Controller Design and Importation The controller fora specific system functionality is typically designed andvalidated in MatlabSimulink using simulations Real-TimeWorkshop (RTW) [27] an automatic code generator inSimulink can subsequently be used to generate the equivalentC code of the designed controller The controller is typicallydesigned in floating-point math while the actual controlsoftware executes on ECUs with potentially limited numberof bits and fixed-point implementation In order to convert

Journal of Control Science and Engineering 5

controller models from floating-point to fixed-point fixed-point Toolbox [28] is used to aid code generation

AlthoughMatlabSimulink provides the environment formodeling and code generation of controllers it lacks the ade-quate and important refinement for controllers that provideimplementation details such as real-time operating system(RTOS) environment timing hardware platform specifica-tions and network considerations Thus after the controllervalidation and generation of equivalent C code in the firststep of our design process the controllerrsquos MatlabSimulinkmodel is automatically imported into the ESMoL envi-ronment by using the MDL2MGA tool in ESMoL TheMDL2MGA tool is a model interpreter that creates a struc-tural replica of the MatlabSimulink model in the ESMoLmodeling environment The replica of the MatlabSimulinkmodel is represented as a synchronous data flow model(SDF) and each subsystem in the replica becomes an actorin the SDF The ESMoL modelrsquos references to the importedSimulink blocks become the functional specifications for theinstances of software components in a logical SDF model Ccode fragments may also be used to specify the componentfunctionality Component ports represent instances of datamessage types These types are defined as structures withindividual data fields to which Simulink data ports can bemappedThese relations describe themarshaling demarshal-ing and transfer of data between software components

412 Logical Software Architecture The second step in thedesign process denoted as B in Figure 2 involves thespecification of the logical software architecture The logicalsoftware architecture model describes the interconnection ofcomponent instances representing the functional blocksThelogical software architecture captures the data dependenciesbetween software components independent of their distribu-tion over different processors The semantics of the logicalinterconnections are defined by task-local synchronous func-tion invocations as well as message transfers between tasksbased on the time-triggered communication paradigm

413 Hardware Platform The third step in the design pro-cess depicted as C in Figure 2 involves the definition ofthe hardware platform on which the controller software isdeployed In this step by specifying the attributes of the hard-ware platform we clearly define the components and interac-tions of the platformwhich significantly impacts the behaviorof the overall control system ESMoLrsquos networkplatform sub-language has several components including processing nodesand communication networks for defining the computingnodes as well as the underlying communication networksSeveral specific networks for automotive systems are definedin this sublanguage such as CAN bus and TTEthernetIn this paper we consider TTEthernet which is based onthe time-triggered paradigm In ESMoL hardware platformsare defined hierarchically as hardware units with ports forinterconnectionsThemodel attributes for hardware platformalso capture timing resolution overhead parameters fordata transfers task context switching times and schedulingpolicies

414 Deployment Model The fourth step in the designprocess denoted as D in Figure 2 involves the definition ofthe deploymentmodelThe deploymentmodel represents themapping of software components to processing nodes anddata messages to communication ports This model capturesthe assignment of component instances as periodic tasksrunning on a particular processor A well-defined specifi-cation of the deployment model is important as the overallbehavior of the control application depends on the efficientmapping of software components to the designated platformsIn ESMoL a task executes on a processing node at a singleperiodic rate and all components within the task executesynchronously Message ports on component instances areassigned to hardware interface ports in the model to definethe media through which messages are transferred

415 Timing Model The fifth step denoted asE in Figure 2involves the specification of the timing behavior of thesystem The timing model allows a designer to specify com-ponent execution constraints involving the timing behaviorof the component The specification of the timing modelis very important in order to ensure the predictability ofthe overall system behavior In ESMoL the timing modelof a control application is established by attaching timingparameter blocks to components and messages There arethree types of timing parameter blocks in ESMoL to representthree different execution modes Time-triggered executioninformation (TTExecInfo) is used to specify the timingfor a task or a message transfer that executes based ona synchronized time base such as in time-triggered dis-tributed system If the synchronized time base is not availableor used an event-triggered system needs to be specifiedIn this case asynchronous periodic execution information(AsyncPeriodicExecInfo) is used for periodic execution whilesporadic execution information (SporadicExecInfo) is usedfor aperiodic execution with a minimum period The modelalso indicates which components and messages that will bescheduled independently and those that should be groupedinto a single task or message object In the case of processor-localmessage transfers transfer time is neglected as reads andwrites occur in locally shared memory

416 Model Transformation In order to integrate analysistools and other code generators into ESMoL rather thandirectly attaching translators directly to the user languageESMoL defines a simpler abstract intermediate languagewhose elements are similar to those of the user languageThesixth step in the design process depicted as F in Figure 2involves this model transformation An ESMoL interpretercalled Stage 1 is used to perform the transformation fromthe originally defined ESMoL model into an abstract inter-mediate language that contains explicit relation objects thatrepresent relationships implied by structures in ESMoL Thistranslation is similar to the way a compiler translates concretesyntax first to an abstract syntax tree and then to intermediatesemantic representations suitable for optimization Stage 1is implemented using the Universal Data Model (UDM)navigation application interface [29] The ESMoL Abstract

6 Journal of Control Science and Engineering

target model is a flattened ESMoL model and the sourcefor the transformations for further analysis and softwarecomponent generations

417 NetworkTask Scheduling This step in the design pro-cess depicted as G in Figure 2 involves network and taskscheduling A scheduler provided by TTTech [30] is used fornetwork scheduling This scheduler requires a configurationscript of the networkhardware platform in order to performanalysis An ESMoL Abstract interpreter called Stage 2 isintegrated into the ESMoLrsquos abstract intermediate languageto generate the TTEthernet configuration script for networkschedulingThis interpreter takes the parameters specified inthe TTEthernet components of the networkplatform modeland combines themwithmessage specifications generated forinterprocessormessage transfers which can be deduced fromthe software architecture model and the deployment modelThe desired offset fields of the TTmessages are obtained fromthe timing model

For the task scheduling we use the bottom-level-basedheuristic scheduling algorithm [31]The algorithm establishesthe critical path of the task graph which needs at least theexecution time of any other path in the task graph In orderto distinguish the tasks on the critical path the notion ofbottom-level of a task is used which is the length of thelongest path starting with this task Because the bottom-levelbounds the start time of a task as-late-as-possible start timeof a task can be used to generate the task schedule

418 Software Implementation The final step in the designprocess depicted asH in Figure 2 is the software implemen-tation of the control software The network schedule fromthe previous design step is used by a tool called TTEBuildfrom TTTech to generate the binary configuration files andC code configurations required for the implementation ofcommunication on the platform An integrated interpreter inESMoLrsquos abstract intermediate language assembles the C codefiles generated by RTW and TTEBuild with glue code filesand automatically generates a Makefile After compilationthe executables are deployed onto the respective ECUs

The proposed software development process andtoolchain provides flexibility and convenience in the rapidprototyping of automotive control software while at thesame time ensuring that the models are correct at thedifferent stages of design In the design of automotive controlapplication it is typical to test multiple configurations andrefinements in multiple iteration Hence the model-basedapproach provides the ability to quickly modify models andparameters to reflect changes and subsequently generatedeployable software components for testing on the platform

5 System Architecture

Figure 3 shows the system architecture for the experimentalplatform used in the evaluation of the automotive softwaredevelopment process

51 Physical Layer Thephysical layermodeling the dynamicsof the automotive system encompasses twomain componentsas described as follows

511 DesignVisualization PC The designvisualization PCrepresents the computing platform running Windows oper-ating system for the dynamic modeling of a vehicle usingCarSim as well as the initial control design and testingusing MatlabSimulink CarSim is a commercially avail-able parameter-based vehicle dynamics modeling softwareIt facilitates the efficient simulation and analysis of thebehavior of four-wheeled vehicles in response to variousinputs such as steering braking and acceleration [32] Thedesignvisualization PC is also used for the visualization andreporting of results from various experiments

512 Target PC The Target PC is a National InstrumentsLabVIEW Real-Time target running NIrsquos Real-Time Modulewhich provides a complete solution for creating reliablestand-alone real-time systems [33] In the experimentalplatform the vehiclersquos physical dynamics modeled in CarSimis deployed on the Target PC during experiments The TargetPC is also integrated with a TTTech PCIe-XMC card [30]which enables the seamless integration and communicationwith ECUs on the time-triggered network supported by theTTEthernet switch

52 Platform Layer The platform layer is modeled bythe TTEthernet switch and ECUs These components aredescribed as follows

521 TTEthernet Development Switch The TTEthernet De-velopment Switch is an 8-port 100Mbps system which sup-ports 100 Base-TX Ethernet and enables hard real-time com-munication based on the TTEthernet protocol It supports astar network topology In Figure 3 the end systems comprisedof the ECUs and the XMC card communicate with eachother through the switch The switch operates based on userdefined configurations based on an experimental scenarioThe configurations are specified in our model-based toolESMoL

522 Electronic Control Units (ECUs) In Figure 3 the net-work depicts four ECUs but there could possibly be more orfewer number of ECUs connected at a time based on a specificconfiguration In our framework an ECU is an IBX-530W-ATOM box with an Intel Atom CPU running a Real-TimeLinux (RT-Linux) operating system Each ECU is integratedwith a TTEthernet Linux driver using an implementation ofthe TTEthernet protocol to enable the communication withother end systems in the TTEthernet network Controllersoftware components are deployed on the ECUs for theexecution of automotive control applications The controllersoftware components that are deployed on each ECU aregenerated from the software design process for the controllerspecified in ESMoL These software components execute inkernel space of the RT-Linux running on each of the ECUsand utilizes the synchronized time base of TTEthernet

Journal of Control Science and Engineering 7

Designvisualization PC

CarSim

MatlabSimulink

NILabView

Windows OS

Target PC

NI VI models

NI EST RTOS

TTEthernet Linux driver

TTEthernet Linux driver

TTEthernet Linux driver

Real-Time Linux

ECU 2

ECU 4ECU 3

ECU 1

Controller C code

Real-Time Linux

Controller C code

Real-Time Linux

Controller C code

TTEthernet Linux driver

TTEthernet Linux driver

Real-Time Linux

Controller C code

TTEthernetdevelopment switch

(8 times100 Mbps)

Figure 3 System Architecture for the Experimental Platform

6 Control Design

In this section we describe the controller design for the ACCThe operation of an ACC involves the use of a radar systemwhich is attached to the front of the vehicle in order to detectwhen a vehicle is in the ACC-equipped vehiclersquos detectableviewWhen a vehicle is detected by the radar the ACC systemwill control the distance between the ACC-enabled vehicleand the leading vehicle In the absence of a leading vehicle inthe ACC-enabled vehiclersquos path the ACC system controls thevehicle to maintain a driver set velocity essentially behavinglike the conventional cruise control system

Thevehiclemodel used for theACCdesign only considersthe longitudinal motion of the vehicle

61 Longitudinal Vehicle Model The longitudinal vehiclemodel is typically based on the following assumptions [17]

A1 The torque converter is locked which implies that theengine speed is algebraically proportional to the vehicle speedvia the gear ratios A2 The tire slip is negligible

The longitudinal dynamics of a vehicle can be describedby the following equation provided that assumptions A1 andA2 hold

119879119890minus 119877119892(119879119887+119872rr + ℎ119865

119886+ 119898119892ℎ sin 120579) = 120573119886 (1)

where

120573 =

[119869119890+ 1198772

119892(119869119908119903

+ 119869119908119891 + 119898ℎ2

)]

119877119892ℎ

119865119886= 119862119886V2

(2)

Table 1 provides a summary of the parameter definitionsFigure 4 shows a block diagram of the ACC systemThe ACCis hierarchically divided into two levels of control the upperlevel controller and the low level controller

611 Upper Level Controller The main functionality of theupper level controller is to compute the desired accelerationfor the ACC-equipped vehicle that achieves the desiredspacing or velocity As depicted in Figure 4 the upper levelcontroller using the driver inputs the radar measurementsand the current distance and velocity of the ACC-equippedvehicle relative to a leading vehicle computes the desiredacceleration that is required to achieve the desired spacingor velocity The computed acceleration command is sent tothe lower level controller to compute and implement thecorresponding actuation commands as needed The upperlevel controller can operate in two main control modes

(a) Velocity Control In this mode the radar does notdetect any vehicle in the path of the ACC-equippedvehicle In this mode the ACC essentially acts like the

8 Journal of Control Science and Engineering

Radar inputs

Driver inputsUpper level

controller controller

Vehicle dynamics

Low level

(range and range rate119886des

120590des

119875mcdes

119907ℎ

119886ℎ

Figure 4 Adaptive cruise control system

Table 1 Parameters for the longitudinal vehicle dynamics

Parameter Definition120573 Lumped inertia119865119886

Aerodynamic drag force119879119890

Net engine torque119879119887

Brake torque119877119892

Gear ratio119872rr Rolling resistance momentsℎ Effective wheel radius119898 Total curb mass of the vehicle119869119890

Inertia of engine119869119908119903

Inertia of rear axle119869119908119891

Inertia of front axle119862119886

Aerodynamic drag coefficientV Velocity of the vehicle119886 Acceleration of vehicle120579 Inclination angle of the road119892 Gravitational acceleration

conventional cruise controller Therefore the ACC-equipped vehiclersquos velocity is maintained at the targetvelocity set by the driver The control law for com-puting the acceleration command is a proportionalcontroller defined as

119886des = 1198701lowast (V119889minus Vℎ) (3)

where 1198701is a control gain V

119889is the user-set velocity

and Vℎis the velocity of the host or ACC-equipped

vehicle(b) Spacing Control The spacing control mode is entered

when the radar detects a leading vehicle in the ACC-equipped vehiclersquos path and the ACC system controlsthe vehicle tomaintain a desired distance based on thevelocity of the host vehicle and a user-specified timegap This desired distance 119878

119889 can be defined as

119878119889= Δ + (V

ℎlowast 119905gap) (4)

where Δ is the desired distance to be maintained in the casewhere the leading vehicle comes to a complete stop and 119905gapis the user-specified time gap with typical values in the rangeof about 07ndash18 seconds

SwitchingThrottle

logic

controller

controllerBrake

119886des

119886res

120590des

119875mcdes

Figure 5 Low level controller

The control law used in computing the desired accelera-tion in this mode is

119886des = min (1198861 1198862) (5)

where 1198861is computed similar to the desired acceleration in

(3) and 1198862is computed as follows

1198862= 1198702lowast (V119897minus V) + 119870

3(119878119889minus 119878119886) (6)

where 119878119886is the gap distance measured by the radar V

119897is the

velocity of the leading vehicle 1198702 and119870

3are control gains

612 Low Level Controller The main objective of the lowlevel controller is twofold First using the desired accelerationcommand from the upper level controller the lower levelcontroller determines whether to apply braking control orthrottle control Secondly the required control commandis applied to the vehicle in order to achieve the desiredacceleration The applied control command is either throttleangle command 120590des or master cylinder pressure command119875119898119888des

(a) Switching Logic The switching logic componentshown in Figure 5 determines based on the desiredacceleration from the upper level controller whethera brake torque or engine torque is required to achievethe desired acceleration Typically it is common toassume that a simple logic for choosing betweenbrake and engine control can be based on the signof the desired acceleration that is if the accelerationis greater than or equal to zero then engine con-trol should be applied otherwise the brake controlshould be applied This approach neglects the factthat with no control inputs the engine torque isnot necessarily zero Thus a better alternative is toconsider the residual acceleration 119886res due to thepresence of engine torque when no control inputs are

Journal of Control Science and Engineering 9

Inverse enginemap

PI

800070006000500040003000200010000

900

50100150200250300350400450500

7062 53463634252010

controller

800700060005000

062 5346363425

Throttle angle

Torq

ue (N

m)

npm

minus

+

+

+

119886des

119886err

120590des

120590119891

120590cmp

119886ℎ

Compute net engine torque

800700060005000

062 346363425

800700060005000

062 534446363425

Throttle

Figure 6 Throttle controller

introduced [16] Based on this approach the enginetorque can be subdivided into two parts minimumor closed throttle torque 119879ect and the portion subjectto control119879ec Substituting these two components for119879119890in (1) we have

119879ec + 119879ect minus 119877119892(119879119887+119872rr + ℎ119865

119886+ 119898119892ℎ sin 120579) = 120573119886

(7)

In the absence of control inputs 119879ec = 119879119887= 0 the

residual acceleration 119886res as a result of closed-throttletorque can be obtained as

119886res =1

120573[119879ect minus 119877

119892(119879119887+119872rr + ℎ119865

119886+ 119898119892ℎ sin 120579)]

(8)

Once the residual acceleration is calculated theswitching law uses the following criteria to determinewhether engine or braking is required

119886des ge 119886res 997904rArr throttle control

119886des lt 119886res 997904rArr brake control(9)

In order to prevent rapid chattering between theengine control and brake control models a smallhysteresis ℎyst is introduced This results in thefollowing switching law

119886des ge 119886res + ℎyst 997904rArr throttle control

119886des lt 119886res minus ℎyst 997904rArr brake control(10)

Once the decision of the control mode is determinedthe corresponding controller converts the desiredacceleration into the appropriate input to the vehicle

(b) Throttle Control When engine control torque isrequired the throttle controller converts the com-puted desired acceleration into a throttle commandthat is required to achieve the acceleration Figure 6shows the block diagram for the throttle control lawThe controller first converts desired acceleration intoa desired engine net torque The desired net torquecan be computed based on (1) with 119879

119887= 0 as follows

119879119890 des = 120573119886des + 119877

119892(119879119887+119872rr + ℎ119865

119886+ 119898119892ℎ sin 120579)

(11)

The computed desired torque is converted into athrottle angle command by using an inverse enginemap for the vehicle based on the current engine speed119908119890 This is performed by interpolating the data from

an experimentally determined engine map lookuptable for the vehicle Consider

119879119890 des 997904rArr inverse engine map 997904rArr 120590

119891 (12)

Due to the potential inaccuracies from the obtainedengine map an additional proportional-integral (PI)controller is integrated in the throttle controller toensure that the desired acceleration is achieved

(c) Brake Control Figure 7 shows the brake controllerWhen braking control torque is required the brakecontroller converts the desired acceleration to an

10 Journal of Control Science and Engineering

Compute Compute119886des

total brake torque desired mastercylinder pressure

119879119887119875mcdes

Figure 7 Brake controller

appropriate brake command The controller firstcomputes the desired brake torque from the desiredacceleration by using (7) and with 119879ec = 0 whichresults in the following equation

119879ect minus 119877119892(119879119887 des +119872rr + ℎ119865

119886+ 119898119892ℎ sin 120579) = 120573119886des

(13)

The computed desired brake torque is then convertedto an equivalent master cylinder pressure which isapplied as the control input to the vehicleThemastercylinder pressure 119875mc can be related to the braketorque by the following equation

119879119887= 119870119887(119875mc minus 119875po) (14)

where 119870119887is a brake gain and 119875po is the push-out

pressure required to engage brake

7 ACC Controller Software Design andImplementation

This section describes the ACC controller software designand implementation based on the proposed developmentprocess The initial ACC controller design is performedin MatlabSimulink Subsequently following the automatedsoftware development process described in Section 4 theMatlabSimulinkmodel is imported into the ESMoL environ-ment

Figure 8 shows the logical software architecture depictingthe logical interconnections of ACC controller componentsIn this model each component represents a task TheACC controller has four tasks Instrument Cluster Sense(InstrClstrSens) Instrument Cluster Actuate (InstrClstrAct)Upper Level Controller (UpperLevelController) and LowLevel Controller (LowLevelController)The InstrClstrSens andInstrClstrAct correspond to the tasks for processing theinputs and outputs of the ACC controller respectively whileUpperLevelController and LowLevelController tasks imple-ment the functionality of the controller designed in Section 6Two tasks InputHandler and OutputHandler are used torepresent the sensing and actuation for the vehicle dynamicsdeveloped in CarSim In addition to the ACC controller wealso introduced another task RearViewMonitor in order toemulate the execution of other tasks on the ECUs

In Figure 9 the networkplatform configurations areexplicitly modeled in the ESMoL Three ECUs are specifiedand are denoted as ECU1 ECU2 and ECU3 The RT-Targetnode represents the Target-PC or computing node where theCarSim vehicle dynamics is executed In order to represent

the sensors and actuators of a vehicle two virtual IO devicesare used For the networked system specific parametersfor TTEthernet need to be defined such as hyperperiodbandwidth time slot size clock synchronization cycle andsynchronization precision These specified parameters areused to generate the TTEthernet configuration script inESMoL

Figure 10 shows the deployment model of ACC controlsoftware Dashed arrows represent assignment of compo-nents to their respective processors and solid lines repre-sent assignment of message instances (component ports) tocommunication channels (port objects) on the processor Wemanually deploy InstrClstrSens and InstrClstrAct on ECU1UpperLevelController on ECU2 and LowLevelController andRearViewMonitor on ECU3

In Figure 11 the timing and executionmodel for tasks andmessage transfers of the ACC control system are shown TheACC controller runs at a period of 10ms Since the TTEth-ernet provides a synchronized time base for communicationall themessage transfers are attachedwithTTExecInfo to indi-cate time-triggered communication For example ULMExecis used to specify the timing for the message transfer fromInstrClstrSens to UpperLevelController We set the followingparameters the execution period which is the hyperperiodof the TTEthernet configuration the desired offset which isused to specify the initstart ns field of TT message in thegenerated TTEthernet configuration script and the worstcase duration which is the worst case communication time ofthe TTEthernet The TTEthernet driver on each ECU has ascheduler that utilizes the synchronized time base which caninvoke the tasks according to a static schedule Thus all thetasks are executed according to the time-triggered paradigmWe specify theTTExecInfo for each task For instanceULExecspecifies the execution time of UpperLevelController in the10ms period Before scheduling we only need to provide theexecution period and the taskrsquos worst case execution timewhich is determined empirically

Using the Stage 1 interpreter as described in Section 4the ESMoL model is transformed to an ESMoL Abstractmodel in the form of XML file A Stage 2 interpreter isused to generate the TTEthernet network configurationfor scheduling and task scheduling In this case of taskscheduling the critical path is simple as follows InputHandler997891rarr InstrClstrSens 997891rarrUpperLevelController 997891rarr LowLevelCon-troller 997891rarr InstrClstrAct After networktask scheduling theschedule information is updated into the ESMoL andESMoL Abstract models automatically The integrated inter-preter then uses the updated ESMoL Abstract model toassemble all the codes for compilation

8 Experimental Evaluation

In this section we present the experimental results from thetesting of the ACC system on the experimental platformThe experiments consist of two vehicles a leading vehicleand an ACC-equipped vehicle which we refer to as the hostvehicle When the ACC feature is enabled and engagedthe host vehicle starts in the velocity control mode and

Journal of Control Science and Engineering 11

Component Component Component

Component Component Component

Low

Ins

LowLow

Mes

Low

HigInp

Inp Inp

Sen

Sen Ins Act

UppRea

Component

RearViewMonitoring

InputHandler InstrClstrAct

InstrClstrSens UpperLevelController LowLevelController

OutputHandler

Figure 8 Logical software architecture of ACC controller

IO device IO device

OCh OChICh IChNode

Node

Node

Node

BCh

BCh

ECU2ECU1

ECU3

BChTTBus

BCh

Acq RT target Act

TTEthernet

OO

I I

B B

B

B

Figure 9 Hardware platform representation of the experimental platform

Table 2 Parameters for the ACC experiments

Parameter Value1198701

051198702

21198703

07Range of ACC radar 100m119905gap 15 sΔ 10m120579 0 radSampling period 001 s119898 1650 kg

maintains a driver-set velocity and when a leading vehicle isdetected the ACC transitions into the spacing control modein order to maintain a desired distance based on the driver-set time gap and host velocity as described in Section 6The parameters for the experiments are provided in Table 2

The experimental setup is based on the system architecturedescribed in Section 5 The generated software componentsfor the ACC are distributed over three ECUs as describedin Section 4 In this experiment the velocity of the leadingvehicle starts at an initial value of 60 kmh The initial globallongitudinal positions of the leading vehicle and the hostvehicle are 130m and 0m respectively which means that thehost vehicle radar is initially out of range The host vehicleinitially starts at an initial velocity of 65 kmhwith a driver settarget velocity of 80 kmh We present four scenarios basedon the driving behavior of the leading vehicle In additionwe compare the results obtained during the control designstage using MatlabSimulink with those obtained from theexperimental platformThe modeled scenarios are describedas follows

(1) Scenario 1 Velocity Control In this scenario there isno leading vehicle in front of the host vehicle withinthe range of the radar and hence the host vehicle isunder the velocity control mode or the conventional

12 Journal of Control Science and Engineering

RearViewMonitoringInputHandler

InstrClstrActInstrClstrSens

UpperLevelController

LowLevelControllerOutputHandler

OChICh

ldquoNoderdquo

ldquoNoderdquo

ldquoNoderdquo

Component Component Component Component

Component

ComponentComponent

BCh

CarDynamics

ldquoNoderdquo

BCh

BCh

BCh Low

LowLow

Low

Mes

Sen Sen

Ins Act

InsInp

InpInp

ReaUpp

Hig

ECU3

ECU1

ECU2

OI

BB

B

B

Figure 10 Platform deployment aspect of ACC controller

Component Component Component

Component

ComponentComponentComponent

Sen

Sen Ins Ins Act

InpMExec

ICSExec

SensMExec

RMExec

RVExec

HLMExec

Inp Inp InpReaUpp Low

Low Low

Mes

Low

Hig

InstrClstrSens UpperLevelController

LowLevelController

RearViewMonitoring

OutputHandlerInstrClstrAct

IMExecActMExec

ICAExec OutMsgExec LLExec

OHExec LLMExec

IHExec

InpExec

ULExec

InputHandler

Figure 11 Timingexecution model of ACC controller

cruise control Figure 12 shows the results fromthe control design phase using MatlabSimulink andthe results from the execution on the experimentalplatform respectively This scenario can be observedbetween the time segment of 0ndash10 s

(2) Scenario 2 Spacing Control In this scenario the radardetects a slower leading vehicle and transitions to the

spacing control mode to control the distance betweenthe two vehicles to a driver-set time gap The desiredgap distance is attained when the two vehicles travelat the same velocity This scenario can be observedbetween the time segment 10ndash40 s in Figure 12

(3) Scenario 3 Leading Vehicle Speeds Up In this scenariowhile in spacing control mode the leading vehicle

Journal of Control Science and Engineering 13

0 20 40 60 80 100 1200

10

20

30

40

50

60

70

80

90

100

110

Time (s)

Velo

city

(Km

h)

Host velocity (platform)Host velocity (Simulink)Lead velocity

(a) Velocity plots

0 20 40 60 80 100 120Time (s)

Dist

ance

(m)

Actual distance (platform)Actual distance (Simulink)Desired distance

0

10

20

30

40

50

60

70

80

90

100

110

(b) Gap distance plots

Figure 12 Gap Distance and Velocities

begins to speed up As a result the velocity of the hostvehicle also increases in order to maintain a desiredvelocity This scenario can be observed between thetime segment 40ndash60 s in Figure 12 From the plotswhen the leading vehicle reaches and a maintainsa velocity of 85 kmh after 60 s the host vehiclemaintains it is velocity at the driver-set velocity of80 kmh since the driver-set velocity is themaximumachievable velocity of the host vehicle based on theACC algorithm It can be seen from the distance plotsthat the distance between the two vehicles increasesdue to the difference in velocity of the vehicles

(4) Scenario 4 Leading Vehicle Slows Down In this sce-nario the leading vehicle slows down and as a resultthe host vehicle also starts to decrease its velocity inorder to maintain the desired spacing between thevehicles This scenario can be observed between thetime segment 70ndash90 s in Figure 12 At approximately105 s the two vehicles starts to travel at the samevelocity again

To highlight the importance of the experimental platformfor the early assessment for control software before actualdeployment on a real vehicle we compared the resultsobtained from running the scenarios in MatlabSimulink tothose obtained from running the scenarios on experimentalplatform This comparison provides insight to potentialimpacts of the deployment of the control software on aprototype platform Figure 13 shows the velocity plots fromthe simulation in MatlabSimulink from the control designstage and the results obtained from deploying the resultingsoftware components on the platform By zooming in on thevelocity plots between 25 and 45 s we notice that compared

25 30 35 40 4555

60

65

70

Time (s)

Velo

city

(Km

h)

Host velocity (platform)Host velocity (Simulink)Lead velocity

Figure 13 Comparison of Simulink simulation results and resultsfrom the experimental platform

to the Simulink results the results from the deployed soft-ware exhibit some oscillations with an amplitude 06 kmhAlthough this is barely noticeable it is important to note thedifference in the results which can be attributed to platformeffects as a result of deploying the controller on the platformThis implementation limitation is due to the fact that thecomputation on the RT-Target is not synchronized with thecommunication

14 Journal of Control Science and Engineering

9 Discussion and Conclusion

Our proposed framework addresses the complex interactionsthat emerge as a result of integrating the various designlayers of CPS The proposed approach provides an end-to-end methodology and a toolchain for the developmentof automotive control software The toolchain is based onsimple and visually intuitive formal languages that restrictcomponent interactions in a well-defined manner in orderto ensure a ldquocorrect-by-constructionrdquo design of automotivecontrol software We employ an experimental platform basedon the time-triggered paradigm in order to facilitate thedesign deployment and hardware-in-the-loop simulationof automotive control software We applied the designmethodology to a case study on the adaptive cruise controland presented the experimental results based on realisticscenarios

In regards to future work we would like to study thepossible interactions between multiple automotive controlsystems deployed together and formally define their interact-ing behavior as well as the impact on the overall systemThisinteracting behavior is important because there are possiblecases where these systems can have conflicting objectivesand hence a clear understanding of their underlying inter-action is crucial

Conflict of Interests

The authors do not have any conflict of interests with any ofthe commercial identities mentioned in this paper

Acknowledgments

The authors would like to thank ShigeWang for his insightfulsuggestions and discussions This work is supported in partby the National Science Foundation (CNS-1035655 and CCF-0820088) US Army Research Office (ARO W911NF-10-1-0005) and Lockheed Martin The views and conclusionscontained herein are those of the authors and should notbe interpreted as necessarily representing the official policiesor endorsements either expressed or implied of the USGovernment

References

[1] J Mossinger ldquoAn insight into the hardware and softwarecomplexity of ecus in vehiclesrdquo in Advances in Computingand Information Technology vol 198 of Communications inComputer and Information Science pp 99ndash106 2011

[2] J Mossinger ldquoSoftware in automotive systemsrdquo IEEE Softwarevol 27 no 2 pp 92ndash94 2010

[3] A Michailidis U Spieth T Ringler B Hedenetz and SKowalewski ldquoTest front loading in early stages of automotivesoftware development based on AUTOSARrdquo in Proceedingsof the Design Automation and Test in Europe Conference andExhibition (DATE rsquo10) pp 435ndash440 March 2010

[4] A Sangiovanni-Vincentelli ldquoElectronic-system design in theautomobile industryrdquo IEEE Micro vol 23 no 3 pp 8ndash18 2003

[5] J A Cook I V Kolmanovsky D McNamara E C Nelsonand K V Prasad ldquoControl computing and communicationstechnologies for the twenty-first century model Trdquo Proceedingsof the IEEE vol 95 no 2 pp 334ndash355 2007

[6] A Sangiovanni-Vincentelli and M Di Natale ldquoEmbeddedsystem design for automotive applicationsrdquo Computer vol 40no 10 pp 42ndash51 2007

[7] T Stahl and M Volter Model-Driven Software DevelopmentJohn Wiley and Sons 2006

[8] J Porter GHemingwayHNine et al ldquoThe esmol language andtools for high-confidence distributed control systems designmdashpart 1 language framework and analysisrdquo Tech Rep ISIS-10-109 Vanderbilt University 2010

[9] A Ledeczi M Maroti A Bakay et al ldquoThe generic modelingenvironmentrdquo inProceedings of the IEEEWorkshop on IntelligentSignal Processing (WISP rsquo01) May 2001

[10] H Kopetz and G Bauer ldquoThe time-triggered architecturerdquoProceedings of the IEEE vol 91 no 1 pp 112ndash126 2003

[11] N Navet Y Song F Simonot-Lion and C Wilwert ldquoTrends inautomotive communication systemsrdquo Proceedings of the IEEEvol 93 no 6 pp 1204ndash1222 2005

[12] M Broy S Chakraborty D Goswami et al ldquoCross-layer anal-ysis testing and verification of automotive control softwarerdquoin Proceedings of the 9th ACM International Conference onEmbedded Software (EMSOFT rsquo11) pp 263ndash272 2011

[13] U Drolia Z Wang Y Pant and R Mangharam ldquoAutoPlugan automotive test-bed for electronic controller unit testingand verificationrdquo in Proceedings of the 14th IEEE InternationalConference on Intelligent Transportation Systems (ITSC rsquo11) pp1187ndash1192 2011

[14] W Hu M Wang and Y Lin ldquoOn the software-based devel-opment and verification of automotive control systemsrdquo inProceedings of the 33rd IEEE Annual Conference of the IndustrialElectronics Society (IECON rsquo07) pp 857ndash862 2007

[15] A Ray I Morschhaeuser C Ackermann R Cleaveland CShelton andCMartin ldquoValidating automotive control softwareusing instrumentation-based verificationrdquo in Proceedings ofthe 24th IEEEACM International Conference on AutomatedSoftware Engineering (ASE rsquo09) pp 15ndash25 November 2009

[16] J C Gerdes and J K Hedrick ldquoVehicle speed and spacingcontrol via coordinated throttle and brake actuationrdquo ControlEngineering Practice vol 5 no 11 pp 1607ndash1614 1997

[17] J K Hedrick and P P Yip ldquoMultiple sliding surface control the-ory and applicationrdquo Journal of Dynamic SystemsMeasurementand Control vol 122 no 4 pp 586ndash593 2000

[18] P A Ioannou and C C Chien ldquoAutonomous intelligent cruisecontrolrdquo IEEE Transactions on Vehicular Technology vol 42 no4 pp 657ndash672 1993

[19] K Yi S Lee and Y D Kwon ldquoAn investigation of intelligentcruise control laws for passenger vehiclesrdquo Journal of Automo-bile Engineering vol 215 no 2 pp 159ndash169 2001

[20] P S Fancher H Peng and Z Bareket ldquoComparative analyses ofthree types of headway control systems for heavy commercialvehiclesrdquo Vehicle System Dynamics vol 25 no 1 pp 139ndash1511996

[21] B A Guvenc and E Kural ldquoAdaptive cruise control simulator alow-cost multiple-driver-in-the-loop simulatorrdquo IEEE ControlSystems Magazine vol 26 no 3 pp 42ndash55 2006

[22] K Breuer and M Weilkes ldquoA versatile test vehicle for acc-systems and componentsrdquo Tech Rep 1999

Journal of Control Science and Engineering 15

[23] A R Girard S Spry and J K Hedrick ldquoIntelligent cruise-control applications real-time embedded hybrid control soft-warerdquo IEEE Robotics and Automation Magazine vol 12 no 1pp 22ndash28 2005

[24] E Armengaud A Tengg M Driussi M Karner C Stegerand R Weiszlig ldquoAutomotive software architecture migrationchallenges from an event-triggered to a time-triggered com-munication schemerdquo in Proceedings of the 7th Workshop onIntelligent Solutions in Embedded Systems (WISES rsquo09) pp 95ndash103 June 2009

[25] J Sztipanovits X Koutsoukos G Karsai et al ldquoToward ascience of cyber-physical system integrationrdquo Proceedings of theIEEE vol 100 no 1 pp 29ndash44 2012

[26] J Eker J W Janneck E A Lee et al ldquoTaming heterogeneitymdashthe ptolemy approachrdquo Proceedings of the IEEE vol 91 no 1 pp127ndash143 2003

[27] MathWorksmdashreal-time workshop httpwwwmathworkscomproductsrtw

[28] B Chou and T Erkkinen ldquoConverting models from floatingpoint to fixed point for production code generationrdquo MatlabDigest November 2008

[29] E Magyari A Bakay A Lang et al ldquoUdm an infrastructurefor implementing domain-specific modeling languagesrdquo inProceedings of the 3rd OOPSLA Workshop on Domain-SpecificModeling Anaheim Calif USA 2003

[30] Ttethernet httpwwwtttechcomenproductsttethernet[31] O Sinnen Task Scheduling for Parallel Systems Wiley-

Interscience New York NY USA 2007[32] Carsim httpwwwcarsimcom[33] National Instruments httpwwwnicom

Submit your manuscripts athttpwwwhindawicom

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2013

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2013Part I

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2013

ISRN Signal Processing

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2013

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2013

Mechanical Engineering

Advances in

Modelling amp Simulation in EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2013

Advances inAcoustics ampVibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2013

ISRN Sensor Networks

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2013

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2013

Electrical and Computer Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2013

DistributedSensor Networks

International Journal of

ISRN Robotics

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2013

International Journal of

Antennas andPropagation

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2013

ISRN Electronics

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2013

Advances inOptoElectronics

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2013

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawi Publishing Corporation httpwwwhindawicom Volume 2013

The Scientific World Journal

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2013

Active and Passive Electronic Components

Chemical EngineeringInternational Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2013

ISRN Civil Engineering

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2013

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2013

thinspJournalthinspofthinsp

Sensors