Architecture-Centric Software Development forCyber-Physical Systems

Oleg Sokolsky, Miroslav Pajic, Nicola Bezzo, and Insup LeePRECISE Center

University of PennsylvaniaPhiladelphia, PA, USA

{sokolsky, pajic, nicbezzo, lee}@seas.upenn.edu

ABSTRACTWe discuss the problem of high-assurance development ofcyber-physical systems. Specifically, we concentrate on theinteraction between the development of the control systemlayer and platform-specific software engineering for systemcomponents. We argue that an architecture-centric approachallows us to streamline the development and increase thelevel of assurance for the resulting system. The case studyof an unmanned ground vehicle illustrates the approach.

1. INTRODUCTIONProblem statement and motivation. Cyber-physicalsystems (CPS) are characterized by a tight interrelation be-tween physical aspects of the system, computational algo-rithms that control and guide the system, and communica-tion between independent entities within the system. Thistight relationship makes design of cyber-physical systemsa challenging problem (e.g., overviews of some modeling,analysis and integration challenges for CPS can be foundin [16, 5]). Design decisions have to take all of these as-pects into consideration, and system modeling and develop-ment tools and languages, such as Ptolemy II [4] and ES-MoL [14], support modeling, simulation and development ofsuch heterogenous systems. For example, Ptolemy II canbe exploited for system design using an actor oriented ap-proach. However, to the best of our knowledge, it only allowsfor the use of actors that are defined within Ptolemy. Simi-larly, the Embedded Systems Modeling Language (ESMoL)is a software architecture language [14] that allows for theintegration of Simulink blocks and existing C code withinTime-Triggered system architectures, while restricting com-ponent interactions that can be specified [16].

Existing CPS development frameworks usually assume theuse of a single tool or tool-ecosystem. On the other hand, inCPS development process, different aspects of system devel-opment are typically handled by different groups within theproject team and require different expertise. Historically,control engineers, embedded software developers, system in-This research is supported in part by DARPA HACMS program underagreement FA8750-12-2-0247 and by GRL Program, NRF of Korea, Min-istry of Science, ICT & Future Planning (2013K1A1A2A02078326). Theviews expressed are those of the authors and may not reflect the official pol-icy or position of the sponsors.Permission is granted to the CPSArch 2014 organizers to distribute this pa-per to the workshop attendees by hosting it, with password protection, onthe workshop website with the understanding that all copyright associatedwith this work is retained with the authors.First Workshop on Cyber-Physical System Architectures and DesignMethodologies (CPSArch 2014) October 17, 2014, New Delhi, India.

tegrators, etc., worked separately. Existing developmenttechniques, deeply entrenched in each of the communities,reflect this separation. However, CPS development demandscloser collaboration between these groups and requires pro-cesses that support such closer collaboration. At the sametime, tighter interaction between different aspects of the sys-tem requires changing the interfaces between these aspects.Control designers should be more aware of capabilities of theembedded platform, while designers of embedded network-ing should take chosen control strategies into account whenplanning communications within the system. This makes in-tegration of the system more challenging, since a change inone aspect of the system renders other aspects inconsistent.Furthermore, it highlights the need to incorporate architec-tural modeling of the system as part of the design process,to ensure that each system component/functionality remainconsistent with any architectural and system changes. Theimportance of the architectural system modeling has led todevelopment of OMG SysML [9] widely used for systems en-gineering, and Architecture Analysis and Design Language(AADL) [6] for modeling of hardware and software architec-tures in embedded systems.

In this paper, we consider a model-based approach toCPS development that aims to support techniques familiarto developers in each of the individual domains and at thesame time facilitate closer interactions between developmentgroups and reduce the challenge of integration of differentaspects together. The motivation for this work comes fromour experience with developing the control system for a rel-atively simple vehicular CPS. We initially applied a model-based approach that relied on model analysis followed bycode generation. However, we have encountered multiplehurdles that had to be overcome through significant man-ual effort at the integration stage. By incorporating archi-tectural modeling into the development approach and us-ing it to drive model analysis, we intend to alleviate thesehurdles, ensure consistency between different model analysisand seamless integration of different system aspects.Challenges. The primary challenge in the CPS develop-ment is the heterogeneous nature of techniques used in theprocess. As a result, abstractions used in different phases ofmodel-based CPS development are very different. Ideally,there should be a common abstraction to base the devel-opment on, or a set of compatible abstractions. However,such a common abstraction that works equally well for allaspects of development seems unlikely, at least in the shortrun. Furthermore, prevalence of certain development toolsin some of the development phases, such as Simulink in the

domain of control systems, makes it difficult to find commonground. This is especially highlighted for tools (includingSimulink) without clearly defined operational semantics Inparticular, Simulink becomes increasingly cumbersome touse once we move into the domain of low-level, platform-specific modeling and code implementation, partially due toits limitations in capturing issues such as concurrency, non-determinism, etc. Even if it was possible to build all thenecessary techniques into a single tool and base them ona common abstraction, we would still face resistance fromdevelopers familiar with prevalent tools in their domains.

Because of this primary challenge, instead of searchingfor a common development approach, we advocate a frame-work that would allow us to use existing development tech-nologies, ensuring their consistent application throughoutthe development process. The use of disparate technolo-gies, however, brings forth the integration challenge, wherecomponents developed using different technologies and bydifferent teams have to be put together in a consistent way.

Integration challenges manifest themselves in multiple waysthroughout the development process and arise through dif-ferent kinds of integration. Here, we consider only a few ofthem. Horizontal integration is encountered whenever differ-ent aspects of the system functionality are developed inde-pendently and yield a collection of modules that operate log-ically concurrently and need to interact with each other. Thechallenges of horizontal integration are typically addressedby using interfaces that allow interaction, while abstractingaway internal details of each module. Traditional interfacedefinitions, however, do not take resource constraints such ascomputation time, communication bandwidth and latency,or power consumption into account. Resource-aware inter-faces have been an active research area for a while. A differ-ent kind of integration challenge is vertical integration, wheredifferent aspects of behavior within a module need to be in-tegrated together. Examples of vertical integration includeextending functional code with fault-tolerance capabilities oradding platform-specific wrappers to platform-independentcode generated by controller design tools.The vision of architecture-centric CPS development.We believe that the challenges of CPS development outlinedabove can be addressed by employing an approach builtaround an architectural model of the system and relying onvirtual integration to build confidence in the system designbefore building it. Virtual integration [8] is a recent conceptin model-based engineering that emphasizes the use of ar-chitectural models to ensure compatibility of independentlydeveloped modules within the architecture. The challengein virtual integration is to find the right amount of detail inthe model to make a trade-off between complexity and pre-cision of analysis. We believe that such an approach wouldallow us to build an effective toolchain for CPS development,utilizing the strong aspects of existing legacy developmenttools to produce appropriate parts of the system implemen-tation and seamlessly tie these parts together using virtualintegration techniques.

2. MOTIVATIONAL EXAMPLEWe are applying such an architecture-centric CPS devel-

opment framework to the case study of control system de-velopment for the LandShark,1 a fully electric unmanned

1See http://www.blackirobotics.com/.

Figure 1: The LandShark vehicle while performingan attack resilient experiment. The user interfaceon the top right of the figure is used to control therobot, attack sensors, and visualize data.

ground vehicle (UGV), shown in Figure 1 performed as partof the DARPA HACMS program. The goal is to develop aresilient system for remotely controlled or autonomous navi-gation that can tolerate both cyber attacks via the teleoper-ation interface, as well as noninvasive attacks on system sen-sors. The effort involves multiple teams working on differentaspects of the system. For our part, we have developed acruise control application, consisting of a controller moduleand a resilient speed estimator (RSE) [13] that provides es-timates to the controller module as well as to other moduleswithin the system. The case study is affected by all of thechallenges outlined in the introduction. At the same time,it has a moderate size and complexity, as well as relativelyrelaxed constraints.

One of the challenges encountered in the case study isthe need to contend with multiple tools that operate ondifferent models and generate code for different aspects ofthe system that need to be integrated. The cruise controlalgorithm was implemented using Simulink, and platform-independent code for it was automatically generated usingSimulink coder. The core of the RSE module solves an op-timization problem using the solver generated by CVXGENtool [10]. Input to the solver involves linear-algebraic manip-ulation of the sensor readings, which was implemented alsousing Simulink. The overall system is developed using ROS,a widely used component-based middleware for robotic sys-tem applications [15]. Each module was deployed as a ROSnode that communicates with other nodes in the system.Thus, the platform-independent code of the controller andRSE modules had to be complemented with ROS interfacecode that performed periodic invocation of the modules andhandled publish-subscribe interactions between nodes.

The initial, rather naive development involved large amountsof manual effort in order to compose the auto-generated partof the code together and deploy it within ROS nodes. Wehad to rethink our development strategy and retarget it frommanual post-implementation integration to automatic vir-tual integration. To enable this new strategy, we used a newdevelopment approach and designed several tools to supportit, which we will describe in the remainder of the paper.

3. DEVELOPMENT APPROACHFigure 2 outlines the development process. The process

comprises of the four distinct stages discussed below.

Modeling phase. Development begins with an architec-tural model of the system. Developers describe the architec-ture of the system, including physical components of the sys-tem, computing and communication infrastructure, as wellas software modules that comprise the system. Attributes ofcomponents depend on the nature of a component. A physi-cal component can specify its weight and dimensions, a pro-cessor can specify its speed and operating system, a softwarecontroller can specify the type of control algorithm, execu-tion frequency or triggering events, and the entry point ofthe software function that implements the controller. An ini-tial model is needed to proceed to other development phases.The model is not fixed and can evolve based on the outcomesof subsequence phases. In particular, outcomes of the anal-yses performed in the transformation phase described belowhelp refine the model and enrich the set of attributes.Transformation and analysis phase. The architecturalmodel is subject to a set of transformations. The purposeof each transformation is to extract an analysis model thattargets a specific analysis technique and has the format ex-pected by the tool performing this analysis. One of the keytransformations for the control system design is the extrac-tion of a mathematical representation of the control system.In the simplest case of such transformation, the softwaremodule in the architecture may specify that it implementsa PID controller, which allows the transformation to yieldthe difference equations for a discrete-time PID controller.Parameters of the controller depend on a model of plantdynamics. We believe that a first-principles plant modelcan also be obtained from attributes of physical componentsin the architectural model. However, this aspect of modeltransformation has not been explored in our case study.

The mathematical representation of the control systemallows conventional control-theoretic analysis of the controlsystem, which allows us to determine parameters of the con-trol algorithm. We further transform this mathematical no-tation into computation-oriented notation that is familiar tocontrol engineers. In our case study, described in Section 2,we use notation similar to the notation used in Simulinkdiagrams. The computation-oriented notation allows us toperform model-based validation of the controllers, as wellas feasibility and performance analysis. In our case study,we performed extensive simulations on the Simulink models.Outcomes of the control-theoretic analysis and validationprovide feedback to the architectural modeling phase, forexample, that the computational infrastructure described inthe architecture does not provide sufficient computationalpower to execute the control system with the desired perfor-mance. In that case, developers may refine the architecture,for example, to introduce more processors and map the RSEmodule and the controller module on different processors.

Other transformations of the architectural model includea model for the analysis of schedulability, which would de-termine, for each software module, its worst-case responsetime and output jitter; and a network-calculus model of thesystem that can be used to determine end-to-end latency ofdata flows through the system and buffer size requirements.Values obtained through this analysis are recorded as addi-tional attributes in the architectural model.Generation phase. Model transformations eventually yieldnotation that is amenable to code generation. The computation-oriented representation for the control algorithm is usedto generate platform-independent control code (“step func-

tion”) using, in our case study, the Simulink Coder tool.Similarly, platform-specific wrappers for control code is gen-erated from the architectural model. Note that both platform-independent and platform-dependent code generation for dif-ferent system modules is performed independently, exploit-ing the natural modularity delineated by the architecturalmodel. In addition, the architectural model can include at-tributes that specify constraints on module operation anddata flows through the system. These constraints can beused to generate monitors that check compliance with theseconstraints at run time.Integration phase. The approach supports virtual inte-gration, that is, the ability to assess feasibility of the inte-grated system before components are built. Virtual integra-tion is also facilitated by the architectural model. Attributesof the model are used for both vertical and horizontal inte-gration. Vertical relations specify which functional code isrunning within the platform-specific wrapper in a moduleand allow us to verify that functional code is correctly in-terfaced with the platform. Horizontal integration is mostlyconcerned with sharing of resources between different nodesin the architecture, ensuring that there is sufficient capacityin the computing platform to run all the software modules,enough bandwidth in the communication platform to ensuretimely communication between the modules, etc. In the casestudy, virtual integration was mostly concerned with check-ing that end-to-end delay from sensor readings to controlactuation is within acceptable bounds. If the virtual in-tegration, which happens in the model analysis phase, hasbeen done right, actual integration of code modules can beexpected to become a straightforward exercise. Our experi-ence with the case study bears this hypothesis out.Framework instantiation. The approach described aboveis general and is not tied to specific modeling tools or deploy-ment platforms. In order to apply the approach, the frame-work needs to be instantiated. Depending on the needs ofa given application and expertise of the development team,we need to choose an architectural modeling language, a toolfor computational modeling and simulation of control algo-rithms, and a deployment platform. Below, we describe aparticular instantiation that we used in the LandShark casestudy. Other languages and tools can be used in instantia-tions just as easily.

4. ARCHITECTURE MODELING: ROSLABROSLab [3] is a modular programming environment for

robotic applications. It has been initially developed to sup-port development based on ROS. ROSLab enables usersto model an architecture of an application that consistsof a set of computational nodes and communication chan-nels between them. The interfaces of some commonly usednodes such as sensor and actuator nodes are pre-defined inROSLab. Users can define a new node and its interface byselecting the channels to add to the interface of the node.While ROS was the initial target platform for ROSLab, theback-end code generation can easily be adapted for otherplatforms. Figure 3 shows an example of the implementa-tion of ROSLab for the creation of a ROS node that receivesa joystick input and sends throttle outputs to a ground vehi-cle like the LandShark in Figure 1. Each block dragged anddropped in the ROSLab workspace is characterized by spe-cific interfaces that contain information such as frequencyof operation, measurements variance, and jitter. This infor-

Figure 2: Outline of the development process

mation is propagated to the mathematical control systemrepresentation block in Figure 2 to create an appropriatemodel for the system.

Figure 3: ROSLab environment: architecture of aremotely controlled ground vehicle

Generation of hardware components. ROSLab wasextended to provide a design environment for creating me-chanical components of robots [12]. A component library ofpredesigned parametrized robotic building blocks are incor-porated into ROSLab. Desired blocks can be dragged intoa workspace, and parameters can be set by the user basedon target specifications. Exposed interfaces on each robotcomponent are represented by ports on the ROSLab block;these ports can be wired together to specify electromechan-ical connections. Assemblies of these blocks can be savedas components in the library to be used in future higher or-der designs. In this way, a full robot can be hierarchicallycomposed from its constituent blocks. Once a robot hasbeen designed, it can be compiled to generate manufactur-ing specifications.

Our vision is to be able to extract a dynamical and kine-matical model from the mechanical model developed thoughROSLab. Physical parameters such as the dimension, weight,and moment of inertia, could be extracted from the designedsystem and then passed to the mathematical control system

representation block in Figure 2 to create a more accuratemodel of the plant. This is subject of on-going research.Generation of platform-dependent software. A ROS-based system usually consists of multiple communicatingROS nodes that can be deployed on the same processor oron different processors connected by a network. ROS nodescan be scheduled to run periodically or in response to in-coming events, and communicate using a publish-subscribemechanism. Nodes exchange messages organized into a setof topics. Platform-independent functional code, such asproduced by control-code generation tools, needs to be con-nected to ROS services using glue code, to which we refer asa ROS wrapper. ROS provides an API to publish messageson selected topics, subscribe to topics of interest, scheduleexecution of the node, etc. Access to messages on the sub-scribed topics requires setting up callback functions that giveaccess to topic buffers. Constructing a ROS wrapper man-ually is an error-prone process that requires detailed under-standing of callback operation, relationship between callbackinvocation and node scheduling, data types of messages onthe subscribed topics, and so on.

ROSLab architectural models contain all the informationnecessary to configure a ROS wrapper. Connections of anode specify subscribed and published topics along withreferences to message types and buffer sizes for subscribedtopics. Attributes of a node specify execution rates andthe interface of the step function. We have implemented awrapper generator using the Coq proof assistant [11]. In ad-dition to eliminating the manual effort needed to constructthe wrapper, wrapper generation allows us to automaticallyconstruct a proof that the wrapper is correctly generatedwith respect to the specification in the ROSLab model.

5. FROM ARCHITECTURAL MODELINGTO CONTROL SYSTEM DESIGN

Architectural modeling also facilitates control system de-sign. The model captures the use of different control mod-ules (blocks) and their interaction. Furthermore, informa-tion from the rest of the architectural model is utilized topopulate some aspects of the system representation. For

example, a significant number of control laws are based ona discrete-time model of the controlled plant (e.g., modelpredictive control algorithms). Our vision is that architec-tural modeling of the physical part of the system (i.e., con-trolled plant) would allow for the automatic extraction of theplant’s model. In addition, schedulability and latency anal-yses provide implementation guarantees such as samplingtimes and jitter, which are used to obtain a discrete-timeplant model. This enables initialization of the controller pa-rameters, effectively resulting in a complete mathematicalrepresentation of the controller.

The complete mathematical representation of the con-trol system provides a basis for control theoretic analysessupported by the design process (e.g., robustness analysisfrom [13] in our case study), and in simple cases could beused for direct generation of the controller code. However,in general, we want to rely on established tools for simula-tion and code generation. We have designed the ACMG toolfor automatic generation of Simulink control models, start-ing from the control system’s complete mathematical rep-resentation. The resulting Simulink model enables closed-loop system simulation to evaluate closed-loop system per-formance. Violation of performance requirements would sig-nal the designer to make changes in the architectural modelto ensure satisfiable control performance. Finally, compu-tational models used for simulation should provide a basisfor code generation. In our development process, we uti-lize Simulink Coder to generate platform independent code(i.e., step function) from the (computational) Simulinkmodel of the controller.

Furthermore, the developed tool exploits the system’s math-ematical representation to provide suitable annotation of thegenerated Simulink blocks and thus, the code generated bySimulink Coder. These annotations present invariants thatthe code has to satisfy, and are used as a basis to obtaincorrectness proofs for generated code.

5.1 Mathematical Representation of SystemsTo capture mathematical representation of a control sys-

tem we use a representation similar to the one used in [1].We describe a system as a tuple C = (V,B,E, S) with:

• A finite set of variables V = Vin∪Vout∪Vl that can bepartitioned into subsets containing input, output, andlocal variables.

• A finite set of system blocks B. Each block b ∈ B hassets of input, output and local variables V b

in, V bout, and

V bl , and we define sets V B

in = ∪b∈BVbin and V B

out =∪b∈BV

bout containing input and output variables of all

blocks. In addition, each block b is associated withfunctional description fb and realization rb (we willdescribe block’s functional description and realizationin the rest of the section). Finally, a system block canitself be a separately described system C′.

• A relation E ⊆ V Bout ∪ Vin × V B

in ∪ Vout representingconnections between system blocks – i.e., a connection

e = (vbi , vb′j ) ∈ E connects an output vbi of block b

to an input vb′

j of block b′, while e1 = (vi, vb′j ) and

e2 = (vbi , vj) ∈ E respectively connect system input

vi ∈ Vin to input vb′

j of block b′ and output vbi of blockb to system output vj ∈ Vout.

• A scope function S : C → {0, 1} specifying whethera unique variable should be associated with the linkduring code generation. Since our goal is to obtaincode annotated with invariants that are predicates oversome of the control system variables, it is necessary toensure that automatic model generation followed bycode generation would not remove the variables as partof code optimization.

A functional representation fb of each block b capturesbehavior of the block, and can be specified as a mapping

fb : V bin × V b

l → V bout × V b

l .

This allows us to describe behaviors of both standard staticand dynamic control algorithms, and finite state machines,along with more complex hierarchical/hybrid controllers.

Finally, realization parameter rb specifies how will thefunctional representation fb be implemented in the gener-ated code. We consider the following three cases. 1) A blockmay correspond directly to an existing component (for ex-ample, a PID controller) in the library of some modelingtool. Currently, we support references to Simulink blocks.2) When there is no pre-built component to implement theblock, the ACMG tool we developed parses fb and creates aSimulink diagram that is used in simulation and code gen-eration. 3) rb can also refer to existing code that will belinked in with the generated code. This supports interfacingwith legacy code and other tools.

5.2 Mathematical Representation ofAttack-Resilient Cruise Controller

The attack-resilient controller used in our case study presentsa composition of the RSE and a standard PID controller,whose input is speed estimation obtained by the RSE. Thecontroller has three inputs, sensor measurement vector y,the last applied engine input ulast, and the desired speed r.The RSE block is represented by

V RSEin = {y,u} V RSE

out = {x}

V RSEl = {y0, ...,yN−1,u0, ...,uN−1,Y,U}.

In addition, functional description fRSE is specified as thefollowing optimization problem:2

x = arg minx∈Rn

‖Y − Φx‖l1/l2 (1)

Φx =[Cx|CAx| . . . |CAN−1x

](2)

Y = [y0|y1| . . . |yN−1] , (3)

yk = yk −k−1∑i=0

CAiBuk−1−i (4)

y0 = y, yk = yk−1, k = 1, ..., N − 1 (5)

u0 = u, uk = uk−1, k = 1, ..., N − 1. (6)

It is worth noting here that matrices A,B and C, whicheffectively specify a linear model of the vehicle, are obtainedin the modeling/transformation phase from the architecturalsystem model that includes a model of the controlled physi-cal process and some of hardware characteristics (e.g., sam-pling rates).

2For a matrix Q ∈ Rp×N , ‖Q‖l1/l2 denotes the sum of l2norms of the matrix rows.

On the other hand, the PID controller’ inputs (desiredinput speed r and speed estimate x) and state xPID areprocessed to produce engine control signal uout. Finally, werely on Simulink for realization of the PID controller, andalgebraic manipulations from Eq. (2)-(6) in the optimizationproblem, while to solve the optimization problem (1) we usecode generated by CVXGEN.

5.3 Automatic Control Model GenerationWe have developed the ACMG tool that transforms the

aforementioned mathematical controller representation intoa Simulink diagram, using the description of Simulink dia-grams from [1]. The tool also automatically integrates exist-ing (non-Matlab) code into Simulink, without the need formanual intervention. To achieve this, we exploit Simulink’ss-functions to include externally generated non-Matlab func-tions. By using s-function API, automatically generatedmodels utilize Matlab Executable (MEX) files (obtained byprecompiling existing code) for simulation, while directly in-corporating the initial code into Simulink Coder-generatedcode. This allows for the use of a single Simulink diagramfor both simulation and code generation.

Finally, the ACMG uses the initial function representationof the system to annotate the obtained Simulink blocks, andthus generated code, with a set of invariants that specify re-lations between blocks’ inputs, outputs and local variables.In our case study, we are exploring the use of Coq-based Ver-ified Software Toolchain (VST) [2] to show that generatedcode correctly implements specified functionalities, startingfrom linear operations specified by Eq. (2)-(6).

6. DISCUSSION AND CONCLUSIONSWe have presented an architecture-centric model-based

approach for the CPS development. The approach is moti-vated by a case study of a control system for an autonomousvehicle. While the case study used ROS as the deploymentplatform, modeling is not specific to ROS and generationtools can be easily adapted to other platforms. Controlmodel transformations implemented by the ACMG tool arecurrently limited to Simulink. However, other computa-tional representations can be supported. Some aspects ofthe described approach are subject of on-going research andimplementation. In particular, ROSLab is being extendedto support more transformations to analysis models, andspecification of physical aspects of the system and extrac-tion of plant models is on-going work. Generation of codeinvariants from the mathematical representation of a con-trol system is an active research area [17, 7]. A full realiza-tion of architecture-centric development paradigm vision isa complex problem that can be achieved only by coordinatedefforts of the CPS research community.

7. REFERENCES[1] R. Alur, A. Kanade, S. Ramesh, and K. C. Shashidhar.

Symbolic analysis for improving simulation coverage ofsimulink/stateflow models. In Proceedings of the 8thACM International Conference on Embedded Software,EMSOFT ’08, pages 89–98, 2008.

[2] A. W. Appel. Verified software toolchain. InProgramming Languages and Systems, pages 1–17.Springer, 2011.

[3] N. Bezzo, J. Park, A. King, P. Geghard, R. Ivanov,and I. Lee. Demo abstract: Roslab – a modularprogramming environment for robotic applications. InACM/IEEE International Conference onCyber-Physical Systems (ICCPS), page 214, 2014.

[4] C. Brooks, E. Lee, X. Liu, S. Neuendorffer, Y. Zhao,and H. Z. (eds.). Ptolemy II - heterogeneousconcurrent modeling and design in java. Technicalreport, University of California, Berkeley, 2005.

[5] P. Derler, E. Lee, and A.-S. Vincentelli. Modelingcyber-physical systems. Proceedings of the IEEE,100(1):13–28, 2012.

[6] P. H. Feiler, D. P. Gluch, and J. J. Hudak. Thearchitecture analysis & design language (aadl): Anintroduction. Technical report, DTIC Document, 2006.

[7] E. Feron. From control systems to control software.Control Systems, IEEE, 30(6):50–71, 2010.

[8] P. H.Feiler, J. Hansson, D. de Niz, and L. Wrage.System architecture virtual integration: An industrialcase study. Technical Report CMU/SEI-2009-TR-017,CMU, 2009.

[9] J. Holt and S. Perry. SysML for Systems Engineering.IET, 2008.

[10] J. Mattingley and S. Boyd. CVXGEN: A codegenerator for embedded convex optimization.Optimization and Engineering, 13(1), 2012.

[11] The Coq development team. The Coq proof assistantreference manual. LogiCal Project, 2004. Version 8.0.

[12] A. Mehta, N. Bezzo, P. Gebhard, B. An, V. Kumar,I. Lee, and D. Rus. A Design Environment for theRapid Specification and Fabrication of PrintableRobots. In nternational Symposium on ExperimentalRobotics (ISER), Marrakech, Morocco, June 2014.

[13] M. Pajic, J. Weimer, N. Bezzo, P. Tabuada,O. Sokolsky, I. Lee, and G. Pappas. Robustness ofattack-resilient state estimators. In Cyber-PhysicalSystems (ICCPS), 2014 ACM/IEEE InternationalConference on, pages 163–174, 2014.

[14] J. Porter, G. Karsai, P. Volgyesi, H. Nine, P. Humke,G. Hemingway, R. Thibodeaux, and J. Sztipanovits.Towards model-based integration of tools andtechniques for embedded control system design,verification, and implementation. In Models inSoftware Engineering, pages 20–34. Springer, 2009.

[15] M. Quigley, B. Gerkey, K. Conley, J. Faust, T. Foote,J. Leibs, E. Berger, R. Wheeler, and A. Y. Ng. ROS:an open-source robot operating system. In Proceedingsof the Open-Source Software workshop at theInternational Conference on Robotics and Automation(ICRA), 2009.

[16] J. Sztipanovits, X. Koutsoukos, G. Karsai,N. Kottenstette, P. Antsaklis, V. Gupta,B. Goodwine, J. Baras, and S. Wang. Toward ascience of cyber-physical system integration.Proceedings of the IEEE, 100(1):29–44, 2012.

[17] T. Wang, R. Jobredeaux, H. Herencia, P.-L. Garoche,A. Dieumegard, E. Feron, and M. Pantel. From designto implementation: an automated, credible autocodingchain for control systems. Preprint arXiv:1307.2641,2013.