TR-ARiSE-2013-001 - MPCmpc.ece.utexas.edu/media/uploads/publishing/TR-2013-001.pdf · an autonomous vehicle). Brace enables integration of phys-ical models with a run-time debugging

Brace: Assertion-Driven Development of Cyber-Physical Systems Applications

TR-ARiSE-2013-001

Xi Zheng, Chien-Liang Fok, Christine Julien, Sarfraz Khurshid, and Miryung Kim

The Center for Advanced Research in Software Engineering Department of Electrical and Computer Engineering The University of Texas at Austin

[email protected], [email protected], [email protected], [email protected], [email protected]

© Copyright 2013 The University of Texas at Austin

Brace: Assertion-Driven Development ofCyber-Physical Systems Applications

Xi Zheng, Chien-Liang Fok, Christine Julien, Sarfraz Khurshid, and Miryung KimThe Center for Advanced Research in Software Engineering

Department of Electrical and Computer Engineering The University of Texas at [email protected], [email protected], [email protected],

[email protected], [email protected]

ABSTRACTDeveloping cyber-physical systems (CPS) is challenging be-cause correctness depends on both logical and physical states,which are difficult to observe collectively. Developers mustrepeatedly rerun the system, often in different physical en-vironments, while observing its behavior. The developersthen tweak the hardware and software until the entire sys-tem appears to meet some minimum requirements. Thisprocess is tedious, error-prone, and lacks rigor. In addition,there are always underlying and often unstated assumptionsabout the physical environment that are subject to vari-ance; these assumptions should be captured early and ex-plicitly in the development process. To address these issues,we present Brace, a framework that allows developers toexplicitly specify both physical and logical assumptions andexpected behaviors. Brace then enables run-time checking ofthese combined physical and logical specifications, providedin the form of assertions, using the physical environmentin which a CPS application is running. Brace uses physicsmodels and temporal semantics to guide CPS developers increating appropriate assertions and to check specified asser-tions for inconsistencies with the physical world. This paperpresents our initial investigation into the requirements andsemantics of such assertions, which we call cyber-physicalassertions, and the realization of cyber-physical assertionswithin the Brace framework. We discuss our experience im-plementing and using Brace with a variety of sensors.

Categories and Subject DescriptorsC.3 [Computer Systems Organization]: Real-time andembedded systems; D.2.4 [Software/Program Verifica-tion]: Assertion checkers, Validation

General TermsDesign, Verification

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.FSE 2013 Saint Petersburg, RussiaCopyright 20XX ACM X-XXXXX-XX-X/XX/XX ...$15.00.

Keywordscyber-physical systems, assertions, debugging

1. INTRODUCTIONA ubiquitous and fundamental challenge in developing

cyber-physical systems (CPS) is that such systems inher-ently integrate both physical and logical components in away that necessitates jointly verifying, validating, and evolv-ing the complete CPS. Existing state-of-the-art techniquesrely on testing in the software and (computer) hardwaredomains, with methods tailored to validating the cyber por-tions of the system. Such approaches neglect key physicalaspects and the interplay between the physical and cyberaspects. Traditional approaches that do combine the cyberand physical focus on calibration activities that tailor thebehavior of the CPS to a particular operating environment.This is contrary to a more direct debugging approach thatfocuses on identifying mismatches between an actual physi-cal environment and the developer’s assumptions about thatenvironment (whether explicit or implicit). Such a mismatchcan even lead to logical errors in the cyber components ofthe system that cannot be reliably solved through calibra-tion. This disconnect between the logical and physical isespecially relevant in many safety-critical CPS, where com-putational elements must correctly assess and manipulatethe state of physical elements in a verifiable manner.

In cyber-physical systems, design, implementation, andtesting often partially or completely neglect concrete mod-els of time and physics that have real impact on CPS ap-plication performance. Consider a simple CPS applicationdeployed in a smart home. When an occupant wants towatch a movie, the smart home must make the environmentdark, so it turns off all of the lights in the room. The smarthome assumes that the room is dark and commences play-back of the movie. An obvious logical programming error ishighlighted by this oversimplified example: turning off thelights in a room does not always make the room dark. Duringthe daytime, it may be necessary to also close the blinds. Increating CPS applications, system developers rely on ad hocimplementation and testing methods: we take a quick crackat implementing a system, throw it in a target environment,observe its behavior, and refine it by fine-tuning its behav-ior. Such an approach is neither reliable nor robust, and itis also not easily generalizable or extensible.

As a second example, consider the safe control of an au-tonomous vehicle tasked with transporting payloads fromone location to another in a specific amount of time. Based

on observations in the development of the vehicle, a CPSdesigner may assume that a given amount of power to themotor for a specified time interval causes the vehicle to movea specific distance. However, if anything changes about theenvironment (e.g., the coefficient of friction of the road sur-face, the incline of the surface, or even the charging levelof the battery), this assumption can fail. If the entire ap-plication is written around a specific set of environmentalassumptions, the entire application can fail. In this case,the application was fine-tuned to a specific operating envi-ronment instead of debugged in the context of specificationsof correct behavior of both the logical and physical compo-nents. In this paper, in contrast, we motivate a debuggingprocess in which the correct behavior of physical componentscan be provided by well-understood models of physics.

Temporal aspects of cyber-physical systems present yetanother challenge. Cyber-physical systems inherently in-clude actuation, or actions that have real impact on a phys-ical world, and actuation takes time. Consider a CPS inwhich a robotically controlled arm flips a light switch off.Debugging the CPS that flips the switch could very reason-ably include checking to ensure that, after the instructionwas issued to the arm, the room became darker. Automateddebugging techniques generally assume that, when a line ofcode is executed, the impact of that execution is effectivelyinstantaneous, and therefore a debugging technique can im-mediately check whether the expected result occurred. How-ever, verifying that the robotic arm successfully turned offthe light requires giving the arm time to do its job. It is notimmediately obvious how to automate checking that suchan actuation was successful without a clear specification ofhow that success relates to the passage of real time.

These examples highlight several aspects novel to cyber-physical systems that makes developing them, and, more tothe point, debugging them, challenging. It is impossible toexhaustively test the complete system for all possible phys-ical states of a target environment. Further, the physicalenvironment may change over time, causing an applicationthat worked at one time to later fail, simply because the newenvironment was not covered in the original testing. Simplystated, existing CPS development and debugging approachesare insufficient because they cannot ensure the correctnessof a program that actuates on a system or environment in away that considers physical ramifications.

To address these challenges, we introduce Brace, a runtimeverification framework targeted to cyber-physical systems.Brace uses assertions over both the cyber and physical prop-erties of an implemented CPS to check its correctness andto provide debugging information to the developer. Braceassertions can incorporate concrete models of the physicalworld (e.g., from a simple understanding of the impact ofactuators on ambient properties of a smart home to a de-tailed kinematic model expressing the expected operation ofan autonomous vehicle). Brace enables integration of phys-ical models with a run-time debugging process. This paperdramatically extends our previous report on Brace [3], whichintroduced the motivation behind Brace, gave a set of toyexamples, and experimented with a rudimentary prototypeconsisting of hard-coded assertion-checking

This paper includes the following components:

• Assertions for CPS. We introduce the idea of usingassertions that relate physical properties, sensed byphysical sensing devices to values of logical variables

as a basis of developing robust cyber-physical systems.• The Brace Framework. We present a framework

for assertion-driven development of cyber-physical sys-tems; this framework provides a novel integration ofthe physical and the logical worlds.• Implementation. We present a generic and flexible

implementation of Brace, which is based on AspectJand the Java Concurrent library.• Evaluation. We describe experimental evaluations

using small representative CPS applications to demon-strate the usefulness and applicability of our frame-work as well to show the importance of supportingtemporal semantics for CPS development.

As opposed to traditional uses of assertions, our assertion-driven approach for CPS development uses physics-basedmodels and temporal semantics to guide creation of asser-tions, to identify inconsistent or infeasible assertions, and tolocalize potential causes for CPS failures and monitor cyber-physical assertions by their temporal attributes. In this pa-per, we describe, demonstrate, and evaluate the Brace toolsfor effectively debugging cyber-physical systems.

2. MOTIVATION AND RELATED WORKAssertions are one of the most useful automated tech-

niques available for detecting and locating faults, even whenfaulty code is executed but does not cause a failure [7]. As-sertion schemes have been extended beyond the domain ofsingle-threaded, relatively deterministic programs to handlethe inherent non-deterministic interleavings of increasinglycommon multi-threaded programs [4]. STROBE [1] sup-ports asynchronous assertion checking for single- and multi-threaded Java programs using copy-on-write semantics toincrementally copy state. JUnit [2], a popular framework fortesting Java programs, provides a number of assert methodsfor easier specification of equality comparisons. A similarapproach for approximate equality comparisons was intro-duced in the Java modeling language [14]. These assertionsare evaluated at runtime to assess the correctness of a pro-gram’s parallelism by checking whether different interleav-ings lead to different results. We have similar challengeswith respect to parallelism, but assertions for cyber-physicalsystems must also allow programmers to refer to the phys-ical environment and assess the relationships between thephysical and logical at runtime.

Attempts to rigorously validate complex cyber-physicalsystems also exist. Instrument-based validation attachesmonitors to controller models during simulation [8]. Ourmotivation requires checking runtime assertions within anactual system as opposed to in simulation and checking as-sertions that span time and multiple nodes. Passive dis-tributed assertions [23] allow developers to add assertionsabout a global network state; each node broadcasts smallamounts of information to a secondary “sniffer network,”which analyzes this data to determine an assertion’s validity.We aim to allow users to explicitly map logical variables tophysical states using a configuration utility, making it eas-ier to write CPS assertions that are also more expressive.Mercadal et al. [17] use a domain-specific Architecture De-scription Language (ADL) to safely handle application- andsystem-level errors in pervasive computing; our initial focusis instead on identifying and reacting to unexpected buggybehavior by using an external sensor network and monitor-

ing process instead of trying to recover from severe errors orinfluence the flow of the original application.

Debugging approaches that connect the logical and phys-ical have been explored in wireless sensor networks. Mari-onette [27] provides rudimentary debugging for sensor net-works using remote procedure call. Sympathy [21] collectsmetrics about the sensor network performance and uses thesemetrics to detect and debug failures. DustMiner [12] iden-tifies potentially faulty sequences of events based on execu-tion traces. Such traces can direct programmers where tolook for logical errors that lead to interactive bugs. Envi-rolog [16] also provides logging capabilities for wireless sen-sor networks; in Envirolog traces can be replayed, aiding inrepeating buggy executions and identifying faults. Declar-ative Tracepoints [5] allows the developer to insert “action-associated checkpoints” using a declarative language. Thesetracepoints enable automating the debugging process. Clair-voyant is a source-level debugger for wireless sensor net-works [28] that connects the developer to the WSN remotelyand then employs fairly standard debugging commands atthe source-level. KleeNet [24], on the other hand, is an off-line symbolic execution tool that for wireless sensor net-works. When KleeNet detects a bug, it automatically gen-erates a test case that demonstrates the bug. Macrodebug-ging [25] addresses the debugging of macroprograms, whichspecify the behavior of an entire wireless sensor network asa unit; individual nodes’ programs are then automaticallygenerated. In macrodebugging, developers can set break-points in the macroprogram and then investigate the tracesin a post-mortem fashion. In the domain of cyber-physicalsystems, we favor live interaction with the program as partof the debugging process; this is because the physical envi-ronment is an inherent part of the system, and the physicalenvironment simply cannot be completely replicated.

Part of our motivation is to identify inconsistencies thatcross the boundaries of a system’s logical and physical com-ponents. Similarly, FIND [9] identifies nodes reporting faultydata so that a developer can localize a node contributing toinconsistencies in reported aggregates. NodeMD [13] wasdeveloped to identify nodes before failures completely dis-able them; by transitioning the node into a diagnostic state,NodeMD identifies and repairs node failures. Also relatedare techniques for automatic calibration [26], whose objec-tive is to fine-tune program parameters to make an ob-served value match a desired value according to a user-defined model. In contrast, our aim is to simplify the processof defining and checking system properties at runtime.

The addition of the CPS perspective provides a fundamen-tal shift from this related work. The fundamental differencebetween our motivation and the above (which is largely tar-geted to wireless sensor networks) is that the CPS developeris interested in asserting properties over both physical andlogical states, and this intricate association with the physicalworld requires dynamic analysis approaches, motivating thedesign of our cyber-physical assertion. At the same time, sig-nificant distribution and resource constraints demand newsemantics for cyber-physical assertion evaluation.

From a practical perspective, we rely on Aspect OrientedProgramming to support our implementation. The Mon-itoring Oriented Programming framework (MOP) [6] usesa similar strategy to provide runtime monitoring in whichmonitors are automatically synthesized from specified prop-erties and are used to check a system’s dynamic behaviors.

When a specification is violated or validated at runtime,user-defined actions are triggered. To use MOP in Java, adeveloper must use a set of logical plugins (e.g., plugins forvarious temporal logics) to specify properties; these logicsare not intuitive and their connection to the program is notoften obvious to a developer. JavaMOP employs AspectJ inits implementation; in Brace we build directly on top of As-pectJ with an optimized concurrency thread manager thathides all the specification, temporal logics, and concurrentprogramming complexity from CPS developers. In Brace,we are motivated to completely hide the runtime monitorsand present only interfaces for developers to specify cyber-physical assertions and connect them to salient physical as-pects of the environment.

Instead of validating CPS application states and criticalconditions on an ad-hoc basis, developers should explicitlyspecify the underlying assumptions connecting the physicalto the logical. Given this motivation and the state-of-the-art, we have identified the following key gaps in supportingexpressive and effective debugging of CPS:

• Physical aspects should be considered duringdevelopment and debugging. Current techniquesto verifying cyber-physical systems implementation in-corporate physical aspects in only an ad hoc and notvery repeatable way. A key challenge in enabling CPSdevelopment is to make consideration of the interplaybetween the physical and logical explicit. Brace achievesthis by defining an assertion language and evaluationframework that allows developers to explicitly referenceexpectations of the physical ramifications of the system.

• Existing debugging techniques targeting tradi-tional systems do not consider the temporal re-quirements of real actuation. Directly adaptingexisting assertion evaluation approaches fails to con-sider the fact that actuation takes real time, while ex-ecuting code takes (almost) no time. Brace uses in-spiration from distributed debugging to consider jointevaluation of physical and logical properties with tem-poral dependencies and over long periods of time.

3. THE BRACE FRAMEWORK FORASSERTION-DRIVEN DEVELOPMENT

A cyber-physical system inherently combines a logical pro-gram that runs within a physical space that can includea variety of sensing and actuation capabilities. The Braceframework directly targets the challenges identified in theprevious section by annotating CPS programs with cyber-physical assertions. These assertions allow a developer toconstrain the appropriate behavior of a CPS application tobe dependent on the logical and physical states jointly.

Using Figure 1 as a guide, we first overview the Braceframework. CPS developers create programs that specifynot only logical function but also physical behaviors in theform of sensing and actuating on an environment. This tar-get environment is shown at the far right of Figure 1. Whena CPS application is running in the context of Brace, it isaugmented with a Brace debugging environment, which mayinclude additional sensing and actuating capabilities. Theselatter capabilities are specific to debugging and are not ex-pected to be available in a real deployment.

Using Brace, a CPS developer can annotate his programby defining cyber-physical assertions. These assertions are

Brace&Configura-on&

U-lity&

Annotated&CPS&Program&

Brace&Framework&

Brace&Force&

Deployable&CPS&Program&

Debugging&Environment&

CPS&Target&Environment&

CPS&&Developers&

CPS&Asser-on&Package&

Figure 1: The Brace Framework Architecture

specified through the Brace configuration interface, and theend result is an annotated CPS program. Given an anno-tated CPS program, Brace connects the annotations to areal physical deployment environment through a providedmapping library we call Brace Force. Brace Force encapsu-lates laws of physics and connects these rules to the phys-ical capabilities of the combined target CPS environmentand debugging environment. During the debugging process,it is the combined environment that Brace assertions areevaluated over. In a real deployment, when the debuggingenvironment is not present, the cyber-physical assertions areeffectively turned off to generate a deployed CPS program.

Consider a set of motivating examples drawn from our ex-periences in the Pharos mobile computing testbed [18]. Thetestbed is built around a set of autonomous mobile vehicleswith three different mobility platforms; the three platformsare shown in Figure 2 and include an iRobot Create with dif-ferential steering, a Segway RMP50 based on Segway’s self-balancing products, and a Traxxas Stampede remote controlcar chassis with Ackerman steering. Pharos is designed toabstract away mobility; for this reason, all three mobilityplatforms are controlled via a single abstraction providedby the Robot Operating System (ROS) [20]. In Pharos,we build cyber-physical applications that operate on top ofthese mobility platforms and interact with the physical en-vironment. The simplest program issues statically definedmovement commands to the mobility platform. This can beextended to a program that, for examples, senses the dis-tance traveled by the platform and issues movement com-mands based on measured progress. This can obviously beextended with additional sensors and actuators to a programthat entails complex interaction with the environment.

Figure 2: The Pharos Autonomous vehicles

In the context of Brace, the autonomous vehicle is a phys-ical entity whose properties (e.g., location and speed) are

captured within the Brace framework and represented asconstructs that can be accessed in cyber-physical assertions.In the debugging environment, capturing these physical prop-erties is accomplished via a set of sensors that can monitorthe designated properties; for example in our testing envi-ronment we can employ an overhead camera that can trackthe movement of the autonomous vehicle.

The cyber-physical program in this example is a programwritten in Java that executes on top of ROS. The developeruses the provided movement libraries to specify the expectedbehavior. The developer’s movement interface implies thatthe results of movement instructions are deterministic: onecan instruct the robot to move a given distance at a specifiedspeed or turn a given angle. The correctness with which therobot performs a movement, however, may depend on a va-riety of factors (e.g., even for a single mobility platform, dif-ferences in surfaces’ coefficients of friction can cause drasticdifferences in movements and turns). Brace assertions allowthe developer to explicitly capture the expectations of theprogram’s behavior, even when that behavior is dependenton or requires interaction with a physical environment. Forexample, a developer may construct a cyber-physical asser-tion, placed after a movement instruction, that asserts thatthe robot has turned a specified degree or was able to movea specified distance in a specified amount of time. By con-necting physical aspects of the environment to the logicalworld, Brace can check these assertions, allowing debuggingthat jointly considers the logical and the physical.

For purposes of exposition, the above assertions over arobot’s movement are simple. More complex assertions maycapture constraints that cross multiple entities. For instance,imagine an application that uses multiple robots to patrola specified area. A cyber-physical assertion in this contextmay specify a required measure of spatial coverage that therobots must maintain for the target space.

In the remainder of this section, we provide details of eachof the components depicted in Figure 1. We first show howcyber assets are linked to physical attributes and how cyber-physical assertions are tightly bound to laws of physics. Wethen concretely define the classes of cyber-physical asser-tions provided in Brace and give their temporal semantics.We then detail the architecture of the Brace framework andoverview its implementation, including the Brace configura-tion interface and Brace Force components.

3.1 Mapping the Physical to the LogicalA cyber-physical system will be evaluated in a debugging

environment that contains a variety of types of sensors thatcan be used to assess the system’s physical aspects whileproviding different levels of precision. Even just assessingthe robot’s location, for example, can be done in myriaddifferent ways given different available debugging environ-ments, for example using ultrasound [19] or RFID [11, 15]indoor positioning systems or GPS outdoors.

As a developer annotates a CPS program with assertionsthat reference both physical and logical aspects of the sys-tem, Brace relies on the sensing capabilities of the targetdebugging environment to present that environment’s vali-dation capabilities. By connecting the logical CPS programwith the physical state of the environment, these assertionscapture the developer’s expectations with respect to the ex-pected impact of the logical instructions (e.g., a move in-struction) on physical properties (e.g., the location of the

robot). The language of assertions also allows the assertionsto capture the influence of external physics (e.g., friction)on the possible physical states.

To accomplish this, Brace introduces two data types: aPhysical Value (pv) and a Mapped Logical Variable (mlv).In Brace, a pv encapsulates the value of some physical vari-able (e.g., the robot’s location or the brightness of a room).It is coupled with a range that quantifies the margin of errorwith which the value is knowable. This accounts for the factthat it may not be possible to measure the precise value ofa physical phenomenon with complete accuracy. Further,physical values of the same type generated by different sen-sors may have different associated ranges.

A Brace mlv, on the other hand, is a logical variable thatis mapped to some selected physical value. It is an internal(logical) representation of the program’s belief of a pv. Atsome level, a mlv is a proxy to one or more sensors that pro-vide the actual value of the physical variable. It provides anaccessor method (public PhysicalValue getValue()) thatreturns the value of the mapped pv. A key element of Braceis that it hides the implementation details of this accessorfrom the developer, separating the essence of assertions andtheir use to debug a CPS program from the specific environ-ment (and composite sensors) that support that debugging.

3.2 Capturing Models of PhysicsA fundamental goal of Brace is to explicitly relate asser-

tions, which capture a developer’s expectations of the be-havior of a CPS program with the models of physics thatgovern the world in which that program executes. Suchmodels play many roles in Brace. They can help define toler-ances on expected behaviors, and they are essential in iden-tifying physical properties’ inter-relationships, especially insafety-critical applications. For example, in an autonomousvehicle-based CPS, physical models can guide specifying as-sertions that the vehicle does not side-slip or roll over. Thisimplies that sensor information must be combined with thesemodels of physics to inform assertion evaluation.

In addition, it is easy to write impossible assertions. Thatis, a developer can assert a behavior that is unachievablegiven a particular operating environment or set of devices.As a very simple example, it may be impossible to increasethe brightness of a particular room beyond a certain level.Likewise certain movement or turning patterns may be un-reasonable for a given autonomous vehicle because of non-holonomic properties. Using models of physics, combinedwith specifications of the available sensors and actuators aspart of the CPS deployment, Brace ultimately aims to guidedevelopers in writing and evaluating assertions using hintsand directives about assertions’ potential validities.

In Brace, a developer can associate a physical model witheach CPS assertion; it is the developer’s responsibility to atleast identify what rules of the physical world govern rea-sonable behavior. A physics model consists of a set of defi-nitions. A definition contains references to multiple mappedlogical variables (mlvs) that in turn ultimately map to des-ignated sensors available in a particular deployment or de-bugging environment (as described above).

When specifying a definition, a developer provides an ab-straction of physical properties. For example, to define aspeed based on underlying mlvs for distance and time, adeveloper can create the following definition:

DEFINE: Speed = DistanceMLV / TimeMLV.

This definition assumes mlvs for both Distance and Timeand that they are relatable to each other. This can be filledin given a sophisticated runtime monitor capable of mon-itoring and computing distances over time. Alternatively,when distance itself cannot be monitored and only locationscan, a developer can create the following defintion:

DEFINE:Speed (t1, t2) =(LocationMLV(t2) LocationMLV(t1)) / (t2 - t1),

where applies the distance formula, and t1 and t2 areplaceholders for two ends of a time window of measurement.

A physics model can also contain relations, which defineconstraints on absolute values that physical variables canhave or constraints on relationships between one or morephysical variables. Relations can include one or more mlvsand can use relational operators (e.g., =, ≤, etc.).

Referring back to the autonomous vehicle example, it ispossible that physics simply does not allow vehicles to movefaster than some specified speed. If that maximum speedis 200 units, this constraint can be provided as part of thephysics model by specifying the following relation:

RELATE: Speed ≤ 200

Such a relation may also be dependent on the particu-lar characteristics of the deployment environment, includingthe availability of particular devices in that environment.For example, the following relates the maximum speed of avehicle to the capabilities of that vehicle:

RELATE: Speed ≤ RobotSPEC.Speed

The following relation limits the maximum brightness of aroom based on both lighting devices and windows:

RELATE: Brightness ≤ dLightBulbSPEC.Brightness,WindowSPEC.Brightnesse

These definitions and relations are not themselves cyber-physical assertions. Instead they capture truth; they arefacts about the physical world that are independent of theaction of the CPS and are not related to a developer’s expec-tations of the behavior of the combination of the system’sphysical and logical components. These expectations are in-stead captured by cyber-physical assertions, which we definenext. Cyber-physical assertions can refer to the physics def-initions, and, more importantly, the physics definitions canguide the creation of cyber-physical assertions, highlightingimpossible expectations and directing reasonable ones.

3.3 Semantics of Cyber-Physical AssertionsLike other assertions, a programmer inserts cyber-physical

assertions at points in the logical program (i.e., the code) todeclare that a certain presumption is true at that point.Unlike other assertions, a cyber-physical assertion’s embod-ied presumption can consider both logical and physical at-tributes, that is, cyber-physical assertions enable developersto explicitly cross the boundary between the physical andlogical. The Brace framework for cyber-physical assertionsalso shields the developer from detailed low-level concernsthat arise in evaluating assertions over physical attributes,necessitated by the interaction with sensors that measurethe physical world. Including physical attributes in asser-tions brings with it several new concerns that arise fromphysical constraints. For example, code-level instructions

(e.g., move) that entail an interaction with or actuation onthe physical environment almost inevitably experience a la-tency between the issuance of the instruction and the com-pletion (or even initiation) of the physical action. Further,measuring aspects of the physical environment is almost al-ways imprecise, and the degree of precision is also dependenton the quality of the sensors used. For these reasons, the se-mantics of cyber-physical assertions are more complicatedthan traditional assertions. In this section, we present thesemantics of the three classes of cyber-physical assertions inBrace; because of the importance of time in CPS, each classdiffers primarily along the temporal dimension.

3.3.1 The Immediate AssertionThe immediate assertion type provides Brace’s closest ana-

log to the semantics of a traditional assertion. An immediateassertion is evaluated synchronously with the program, i.e.,the application thread that executes the assertion pausesthe cyber-physical program until the assertion is completelyevaluated and determined to be either true of false. An as-sertion specifies logical constraints on physical (and logical)values; Brace allows a variety of comparison operators to beused in specifying assertions. As a nod to the physical envi-ronment, there is one additional component to an immediateassertion in Brace: a tolerance value that allows some wiggleroom in assessing the physical value.

The ability to mimic the semantics of a traditional asser-tion is essential in Brace. However, the immediate assertionalso has several drawbacks and limitations. First, dependingon the types of sensors included in the underlying debuggingenvironment and connected in through the physics model,evaluating the assertion may incur significant latency. Forexample, an assertion may require interacting with a dis-tributed set of sensors that may be duty cycled (i.e., allowedto periodically sleep to conserve energy). This latency hasan impact on the calling thread from which the assertionoriginates, delaying its future actions. Thus, the behavior ofthe application in the presence of the assertions may differfrom the behavior of the application in the absence of any as-sertions. In addition, physical values read from sensors usedto evaluate the assertion may be out of date with respect towhen the developer intended the assertion to be triggered,especially if significant latency is incurred in communicatingwith the sensors. Finally, as expected, an immediate asser-tion is evaluated immediately, but this immediacy may notallow time for actuation to happen, causing assertions thatreally should evaluate to true (i.e., the robot is about to bemoving) instead evaluate to false.

The limitations associated with Brace’s immediate asser-tions are fundamental to systems that consider physical prop-erties, but they are also fundamentally new in comparisonto existing assertion capabilities. To account differently forthese limitations in CPS programs, we introduce two addi-tional types of cyber-physical assertions.

Example. We use the following immediate assertion inour evaluation (in Section 4) to assert that the ambientsound level is greater than a specified decibel level (withina specified tolerance):

ASSERT IMMEDIATE: Sound > 10 ± 0.1

Applicability. Brace evaluates these assertions immedi-ately and returns the result directly to the application, inline with the running program.

Limitations. When used with sensors that incur delays,the calling thread is delayed, potentially changing its seman-tics. When used to validate actuation behavior, immediateassertions may not be able to capture real physical delays.

3.3.2 The Asynchronous AssertionTo mask the latency incurred by immediate assertions,

Brace introduces asynchronous assertions, in which the pro-gram can continue to execute while the assertion is evaluatedin the background. By allowing the program to continuerunning, the application’s responsiveness (as perceived by auser) is less impacted. The semantics of asynchronous as-sertions are, however, complicated by the fact that they arenot evaluated instantaneously. Asynchronous assertions areparticularly useful when the data used to evaluate the as-sertion must be collected from multiple devices distributedin the cyber-physical network since the network communica-tion required to collect the needed values only increases thedelay of assertion checking. Executing an asynchronous as-sertion allows the cyber-physical program to continue, but ifthe assertion is deemed to be falsified, the host program canbe notified by a user-defined response action (i.e., a call-back) attached to the assertion. One consequence is thatthe program is likely to execute beyond where the assertionoccurred, making fault localization more difficult since thefault has potentially had time to propagate.

A second motivation for the asynchronous assertion inBrace arose from an observation about cyber-physical sys-tems behavior, namely that there is physical latency asso-ciated with actuation commands. That is, physical actua-tion is not immediately connected to the logical instructionsthat trigger it. Further there are inherent latencies with re-spect to an action being performed and that action havingthe desired effect. Take a simple example: a smart homeapplication may have an instruction that sets the home’sthermostat to 68 degrees Fahrenheit. Immediately followingthis instruction with an assertion that asserts that the tem-perature in the home is 68 degrees is obviously unreasonablesince it takes the home’s heating and cooling system sometime to effect a temperature adjustment. The nature of thisdelay is common across many actuations, but the length ofthe delay is highly variable and depends on the physical vari-able, the particular actuators used, and the sensors used.

To address these issues, Brace’s asynchronous assertionscan specify a delay parameter that indicates how long thesystem should wait before attempting to evaluate the asser-tion. In addition, asynchronous assertions can also associatea time-to-live window with each assertion. The semantics ofthe assertion evaluation are such that, if the assertion istriggered at time t, it must evaluate to true in the interval[t0+delay , t0+delay+window ]. Finally, Brace also allows theassertion to specify the number of attempts that its expres-sion should be evaluated and the interval of time betweenthese evaluations. An assertion fails if the majority of theseattempts fail. This latter parameter may appear to be at alevel of detail that is too fine for the assertion programmer,but it allows control over the (potentially high) overheadassociated with evaluating an assertion repeatedly.

A subtle complication related to evaluating asynchronousassertions rests in determining what data is used to evalu-ate the assertion. Consider a simple example assertion thathas to collect and then average location estimates for an au-tonomous vehicle from multiple distributed location sensors.

In an immediate assertion, the entire system is assumed tohalt, the assertion is checked (in a distributed way), andthen the system resumes (or halts, if the assertion fails).In an asynchronous assertion, the assertion is triggered andevaluated in the background by the runtime monitor (de-scribed in the next section), while the system continues. Thetriggered assertion executing in the runtime monitor collectsthe location estimates from the multiple distributed locationsensors. Assume that the assertion was triggered at time t0and that, by the time the assertion thread gets results fortwo of the location sensors, the location readings are asso-ciated with times t0 + ∆1 and t0 + ∆2. These two valuesare associated not only with a different time than that ofthe assertion but also with different times relative to eachother. Either of these differences may impact the correct-ness of the assertion evaluation, depending on the intent ofthe assertion. As a result, the program may experience afalse negative (or a false positive) in assertion reporting.

Example. The following example assertion, used in ourevaluation in Section 4, extends the immediate assertionabove. It asynchronously checks whether the sound is abovea threshold (within a tolerance) after a delay of 500ms. Itis checked three times in the following second, ending in theinvalid callback if the assertion is falsified a majority of thetimes and in the valid callback otherwise.

ASSERT ASYNC: Sound > 10 ± 0.1delay = 500, window = 1000, attempts = 3validCallback = SoundValid()invalidCallback = SoundInvalid()

Applicability. Brace evaluates these assertions asyn-chronously and returns the result to the calling applicationthrough a callback function. Asynchronous assertions cancapture physical values with high accuracy while allowingfor tolerance in the temporal evaluation of the assertion.

Limitations. Tuning appropriate values of delay, win-dow, and attempts may be specific to particular physicalvalues, and setting parameters innapropriately may result inlost accuracy or large unnecessary latencies. Asynchronousassertions must also deal with discrepancies in the time stampsassociated with the data used to evaluate them.

3.3.3 The Continuous AssertionIt is not uncommon in CPS applications to have conditions

that ought to remain true throughout an extended portionof lifetime of the system. In Brace, a continuous assertionis one that spans a period of time over which the assertionis periodically checked. Such assertions may span multiplenodes, locations, and time frames. These assertions effec-tively define program invariants because they are requiredto be continuously evaluated over the program’s execution,instead of executed singularly at a particular point in theapplication’s code. If the execution of the system could bediscretized into a sequence of actions, these assertions wouldbe evaluated after every action. In reality, Brace uses a realtime multi-threaded monitor to continuously evaluate theseassertions without interfering with the application’s execu-tion. In an autonomous robot application, a continuous as-sertion may be used to monitor wither the robot remainswithin a certain region of space. In a smart home scenario,a continuous assertion may declare that the temperature ofa room must never be above or below specified thresholds.The semantics of continuous assertions are even more com-plex than asynchronous assertions. We must consider the

overhead of the frequency of evaluating continuous asser-tions. Clearly the overhead of evaluating them constantly(e.g., after every instruction) is often unacceptable. How-ever, evaluating them too infrequently can lead to inade-quate knowledge in the conditions that cause assertions tofail (or it may cause Brace to miss many cases where the as-sertion is in fact falsified). Therefore continuous assertionsalso specify the frequency with which they are evaluated,putting the control over these potential inconsistencies inthe hands of the application domain expert.

Example. The following example continuous assertion isslightly different from the asynchronous assertion above inthat, as a continuous assertion, it simply checks the soundvalue once every second:

ASSERT CONT: Sound > 10 ± 0.1interval = 1000validCallback = SoundValid()invalidCallback = SoundInvalid()

Applicability. Brace evaluates these assertions continu-ously, and because they effectively inherit from asynchronousassertions, they can capture physical values with high ac-curacy. Continuous assertions are essential for monitoringsystem invariants over the lifetime of the CPS.

Limitations. Like asynchronous assertions, the valuesused in evaluating a continuous assertion may be distancedin time from the determination of a false instance, so tracingthe actual failure condition may be non-trivial. Also, tun-ing the parameter (i.e., interval) may be dependent on theparticular physical variable and/or sensing capabilities.

3.4 Implementing the Brace FrameworkBrace provides a set of Java APIs that enable CPS devel-

opers to define cyber-physical assertions. As one of our goalsis to minimize the learning curve for CPS developers to spec-ify these assertions, we encapsulate the entire Brace frame-work in a library and provide this intuitive utility to enabledevelopers to specify assertions abstractly. Starting with thedeveloper on the far left of Figure 1, before the developercreates an annotated CPS application, he first interacts withthe Brace configuration utility to specify his cyber-physicalassertions. In Brace’s current implementation, developerscreate cyber-physical assertions using an XML schema thatencapsulates all of the properties and parameters describedin the previous section; in the future, directly providing theXML can be replaced with an even more intuitive (and con-cise) representation that can be automatically mapped intoa more machine readable format. Each assertion has a name,which is used by the developers use to insert assertions intothe CPS program. The Brace configuration utility automat-ically generates a cyber-physical assertion package contain-ing Java class files that associate each assertion with a publicstatic Java method that can be invoked in the CPS programusing a one-line Java statement.

In the case of immediate assertions, these one-line calls inthe annotated program are simply (blocking) method calls;in the case of asynchronous and continuous assertions, aBrace runtime monitor, which is built on top of AspectJ, isused to store these assertions in a lock-free concurrent linkedlist [10]. During runtime execution, the runtime monitor as-signs threads to evaluate the assertions in this list. Theassertion’s implementation includes the callback function,which is invoked upon completion of the assertion evalua-tion. If the assertion is continuous, it is placed back in the

list for subsequent evaluation.The above process requires the definition of each of the

components depicted in Figure 11. The developer definesthe assertion using the Brace configuration utility. Then thephysical capabilities of the target environment must be con-sidered by mapping the physical variables (pvs) that can besensed to mapped logical variables (mlvs). This needs to bedone once for any target environment and is also currentlyaccomplished through an XML schema. Third, rules govern-ing physics must be specified as rules of the form shown inSection 3.2. Conceptually, Brace provides a universe of rulesthat connect high-level variables to mapped logical variablesthat may or may not be available in a particular environ-ment. Connecting the available pvs to the mlvs defines thecapabilities of the environment and constrains the allow-able cyber-physical assertions. That is, only mlvs that canbe supported by available pvs can be referenced in cyber-physical assertions used in the CPS program.

4. EVALUATIONIn this section, we evaluate the Brace framework in two

ways. First, the fidelity of the framework is evaluated bydemonstrating the consistency with which the cyber-physicalassertions are able to track the actual physical state of theworld. We also empirically ascertain the impact of cyber-physical assertions on the application behavior itself. Inall cases, we use a simple ambient intelligence applicationthat mimics a simple home automation application in whichsound, light, and temperature controls are available to aCPS application developer.

Test Environment. Our testing environment consists ofa series of sensors and actuators that enable interaction withand sensing of the ambient environment. Figure 3 shows thehardware configuration we used for our mock home automa-tion environment. Not depicted are the sound control (whichis built into the laptop) and the temperature control, whichwas done with the home’s thermostat.

User’s&PC&

Arduino&Mega&2560&

Brace8Annotated&Applica<on&ROS&Node&ROS&Core&

SRF08&&Light&Sensor&

HiTec&HS8645MG&&Ultra&Torque&Servo&&

Light&Switch&

USB&

ZX8Sound&Sensor&Grid8EYE&IR&and&

Temperature&Sensor&

Figure 3: Test Environment Configuration

The laptop used was an Intel i5-2410 2.3GHz quad corewith 3.9G of memory and running Ubuntu 12.04 and Javaversion 1.6. The sound is generated on the laptop at vary-ing decibel levels using the Java Sound Library. This isconnected to an Arduino Mega 2560 board, which providesa bridge to the sensing and actuating devices. For the soundsensor, we use a ZX-Sound sensor, for the light sensor, we usean SRF08 ranger/light sensor, and for temperature sensing,we use a Panasonic Grid-EYE infrared array sensor. Thelight sensor measures the ambient light level at 10Hz and

1The detailed XML specifications are omitted for brevity.They can be found at http://mpc.ece.utexas.edu/brace

sends the measurements through the Arduino to the laptop.To control the light levels, we use a servo attached to a lightswitch that controls a set of fluorescent ceiling lights.

Depending on the scenario, our smart home applicationmay generate sound, control the light switch, or both. Inaddition, in different evaluations it is annotated with dif-ferent immediate, asynchronous, and continuous assertionswith a variety of parameters detailed within each experi-ment description. Alongside the CPS application, the testlaptop runs Brace Force to connect the cyber-physical asser-tions to the physical environment and the Brace frameworkto monitor and evaluate the active cyber-physical assertions.

Brace Framework Fidelity. Our first tests evaluate thefidelity of the Brace framework. That is, the goal is to eval-uate the consistency with which Brace assertions are ableto reflect the ground truth of the physical environment. Inmany ways, this is more an evaluation of our selected sensorsthan it is of the Brace framework itself, but it demonstratesthe capabilities of the framework within a reasonable envi-ronment with off-the-shelf monitoring capabilities that onecould reasonably expect to have in debugging a CPS appli-cation for home automation. We first examine the ability ofimmediate and asynchronous assertions to validate a singleactuation action. Specifically, we created a program thatissues a command to increase the ambient decibel level to4.5 (the decibel level is initially near 0). Immediately afterthis call, we assert that the ambient decibel level is greaterthan a certain threshold. We show results for fifteen dif-ferent forms of this assertion: for five different thresholdvolumes, we specify one each of an immediate assertion, anasynchronous assertion with a one second delay and a singleattempt, and an asynchronous assertion with a one seconddelay and 3 attempts, each separated by a half second.

Commanded(Level(

0(

10(

20(

30(

40(

50(

60(

70(

80(

90(

100(

0( 1( 2( 3( 4( 5(

Invalid

(Asser-o

ns((P

ercent)(

Asser-on(Threshold(Decibel(Level(

Immediate(

1s(delay(1(a;empt(

1s(delay(3(a;empts(

Figure 4: Sound Fidelity Test

Figure 4 shows the results of executing these three dif-ferent assertions with the five threshold decibel levels. Eachpoint plots the percentage of times out of 20 invocations thatthe evaluated assertion was false. The gray areas depict theregion where the decibel level in the assertion’s expressionwas below the commanded level (the assertion should cor-rectly evaluate to true), and the white area is where theexpression’s decibel level was above the commanded level(the assertion should correctly evaluate to false). The im-mediate assertion never evaluated to true. This is becausethe immediate assertion directly follows the sound actua-tion in the logical code, which does not allow time for the

physical actuation to happen. This demonstrates one of thefundamental motivations of Brace: the need for an assertionlanguage that explicitly considers the temporal nature of realCPS applications. For the asynchronous assertions, in thehashed area, we expect that each assertion should evaluateto true, but there was inconsistency in Brace’s performance.More reliable sensors (or multi-modal sensing that combinesreadings for the same physical value from multiple types ofsensors) would decrease the width of this hashed area, pro-viding an even higher quality of assertion correctness. In ad-dition, different settings for the asynchronous assertion canhelp mitigate these concerns, for example providing longerdelays, longer windows, or more attempts.

To drill down with respect to the impact of actuation de-lay on Brace’s ability to successfully evaluate assertions, wetake an example using the light switch and light sensor. Inthis experiment, our CPS application starts with the lighton, turns it off, waits four seconds, then turns it back on. Tounderstand the latency in the actuator and the sensor, weexecuted this snippet of our applications forty times. Fig-ure 5 shows an actual trace of how the room’s ambient lightlevel changes throughout a single execution of the applica-tion. The program issues a command to turn off the lightsat time t = 1, but the room’s brightness does not actuallydim until time t = 1 + Toff . Likewise, the program issuesa command to turn on the lights at time t = 5, but theroom does not actually brighten until time t = 5 + Ton. Onaverage across our forty trials, Toff = 386.60±11.21ms andTon = 492.65±11.00ms, where the ranges denote 95% confi-dence intervals. The difference between Toff and Ton reflecta possible bias in the way the servo is attached to the lightswitch and the fact that fluorescent lights take time to turnon due to the use of a ballast. These concerns reflect thepractical challenges that exist in debugging cyber-physicalsystems in comparison to debugging traditional programs.

0"

50"

100"

150"

200"

250"

300"

0" 1" 2" 3" 4" 5" 6" 7"

Light&M

easuremen

t&(Higher&is&Brig

hter)&

Time&(Seconds)&Lights"off"command"issued" Lights"on"command"issued"

Toff" Ton"

Figure 5: Brightness during application execution

From the application’s prospective, issuing the actuatingcommands on the light switch is relatively quick. Over 40rounds (80 actuation commands), the average software (i.e.,cyber) latency is only 0.13±0.09ms, which is negligible rel-ative to Toff and Ton. This difference between cyber andphysical latencies demonstrates the necessity of using asyn-chronous cyber-physical assertions with delay windows thataccount for actuation and sensing latencies.

A Continuous Assertion. To demonstrate the use ofa continuous assertion, we describe two examples: one pro-

vides assertions over the light level in the room, and theother provides assertions over the temperature in the room.In the first case, we used three different continuous asser-tions that assert that, continuously, the light level in theroom should not fall below a specified level of lumens. Onthe actuation side, our program then alternates the light onand off every 120 seconds. While we evaluated a variety ofsettings for such a continuous setting, we include the traceof a single execution, shown in Figure 6, which is for a con-tinuous assertion with a 500 millisecond delay window.

0" 120" 240" 360" 480" 600"Time%(seconds)%

On"

Off"

Figure 6: A Continuous Assertion

The white areas represent times when the light was on,and the gray areas represent times when the light was off.For clarity, the line tracks a representation of the assertion’sbelief about the state of the light (either “on” (high) or “off”(low)); in this case, “off” corresponds to cases when the as-sertion was triggered. The continuous assertion tracks thevalue of the physical variable decently well, modulo a delaythat comes from a delay in sensing and actuating. In addi-tion, an erroneous evaluation at approximately 470 secondsinto the experiment indicates an instance when the assertionwas not triggered, even though the light was off.

Our second continuous assertion experiment used an as-sertion to monitor the ambient temperature of the environ-ment over a longer period of time. We changed the thermo-stat’s setting every five minutes and used a pair of assertionsto validate that the room’s temperature remained within aspecified range for the duration of the test. We tested undera variety of temperature settings and assertion ranges. Aplot of the results is removed for brevity, but these contin-uous assertions were also able to track the physical variablewell. We did find in this case that it was more effective tocheck the physical value over a longer time window and withmultiple attempts; this is because the temperature valueis slow to change, and the rate of change is unpredictableacross instances. This demonstrates that CPS applicationsrequire the debugging flexibility that Brace provides in thedelay, window, attempts, and interval parameters includedin the asynchronous and continuous assertions.

The Impact of Instrumentation. An important as-pect of Brace is its ability to separate its behavior from thatof the CPS application. There is a danger of the overheadof evaluating Brace assertions changing the behavior of theapplication itself. This is dangerous because, when the de-veloper is ready to deploy the application, he will remove theBrace annotations from his program and expect the behaviorto remain unchanged. To begin to ascertain the potential forBrace’s instrumentation of the CPS application to interfere

with the application, we evaluate the quality of assertionevaluation (the only way we have to assess the program’scorrectness) under increasing assertion loads.

Specifically, consider the simple light control snippet ofour home automation application. Using the Brace config-uration utility, we generated cyber-physical assertions withrandom selections of assertion types (immediate, asynchronous,or continuous), random selections of assertion thresholds forthe light value, and random selection of the assertion param-eters (delay, window, attempts, and interval). We removethe impact of actuation latency on assertion evaluation byinserting a software delay between the actuation action andthe assertion trigger. Figure 7 shows the results.

100# 99# 97# 95#

0#

10#

20#

30#

40#

50#

60#

70#

80#

90#

100#

0# 500# 1000# 1500# 2000#

Success&R

ate&(Percent)&

Number&of&Asser5ons&

Figure 7: The Impact of Instrumentation

The figure shows the percentage of the assertions thatevaluated correctly. Incorrect evaluations consist of bothincorrect results (the assertion should have been triggeredbut was not and vice versa) and assertions that time out(i.e., those that fail to be scheduled before the expiration oftheir specified delay). As the number of assertions grows,the number of failures increases slightly. This is of coursedependent on the hardware configuration, but even for largenumbers of assertions on a common-place laptop configu-ration, Brace performs with high dependency, lending cre-dence to the claim that evaluating Brace assertions has littleimpact on the execution of the CPS application under test.

5. DISCUSSION AND FUTURE WORKTo further explore the connection of cyber-physical asser-

tions with physics models, we developed a physics modelfor the motion of an iRobot Create robot, given its specifi-cations. We outfitted the robot with a motion sensor andimplemented a small controller instrumented with a cyber-physical assertion that checks if the wheel speed is 0.5m/s.As the robot moves, the assertion holds true when the robotmoves on a smooth surface but fails when the robot moves oncarpet. This experiment demonstrates how cyber-physicalassertions are tightly bound to the physics models; ignor-ing the models (i.e., in this case the surface coefficient offriction) can lead to faults in CPS applications.

This motivates inclusion of physics rules in Brace as de-scribed in Section 3.2. We envision that cyber-physical as-sertions that incorporate even more complex physics modelswill be applied to real-world CPS applications, including andespecially mission-critical ones. Consider the domain of au-tonomous vehicles. Some existing high-end passenger carsalready use cameras, radars, lasers, and GPS for automat-

ing various operations, such as blind-spot monitoring, lanedetection, adaptive cruise control, and parallel parking. Tofacilitate the development and validation of such CPS appli-cations, we envision support for representing and monitoringmore complex physics models, say even to track how the be-havior of adjacent vehicles may influence the safety of thehost vehicle. A simple example assertion can constrain thespeed of the host vehicle to be no more than the one aheadto maintain a safe distance. We can create the followingphysics model coupled with the subsequent assertion:

DEFINE: MySpeed = MyDistanceMLV / TimeMLV

DEFINE: FrontCarSpeed = FrontCarDistanceMLV / TimeMLV

ASSERT CONT: MySpeed ≤ FrontCarSpeed

Future work will also explore the potential use of physicsmodels as part of the development process. We should beable to allow the developer to write some code, write an as-sertion, and have the physics model communicate, at com-pile time, that the assertion is an unreasonable expectationgiven the physical laws of the target environment.

Another topic we will explore is the use of physics modelsto improve the quality of sensor data acquisition and reduceits cost, which can be significant in many CPS domains.Achieving extended lifetime for these energy-constrained de-vices is non-trivial, where communication with the sensorscauses the biggest energy drain but is required to acquiresensor readings. Recent work [22] has motivated using model-driven data acquisition for predicting trends of sensed dataand incurring sensing cost only when readings deviate fromthe expected trends. We can adopt a similar approach inBrace. This will be especially useful in evaluating long-livedcontinuous assertions where the model underlying physicalphenomenon is predictable or does not change rapidly.

6. CONCLUSIONAs CPS applications become increasingly prevalent and

sophisticated, new tools are needed to simplify and makemore robust their development. In developing CPS appli-cations, there are a few key challenges related to tempo-ral conditions, physics models, and unchecked presumptionsabout the physical entites and the environment that mustbe considered during the debugging process. Furthermore,existing techniques are ad hoc and treat logical and phys-ical states disjointly. We introduced Brace, a frameworkthat provides an interface for defining cyber-physical asser-tions and runtime support for evaluating them. Using cyber-physical assertions, developers can assert the expected rela-tionships between logical variables and physical properties,capture critical assumptions in the form of cyber-physicalassertions, and closely bind those assertions with temporalconditions. We presented a prototype implementation ofBrace and a small evaluation that demonstrates the fidelityof Brace’s assertion evaluation and the impact of assertionson the behavior of an instrumented CPS application.

7. ACKNOWLEDGMENTSThis work was supported in part by the NSF under grants

CCF-1149391, CCF-1117902, CCF-1043810, SHF-0910818,and CCF-0811524 and Microsoft SEIF award. Any opinions,findings and conclusions or recomendations expressed in thismaterial are those of the authors and do not necessarilyreflect the views of the sponsoring parties.

8. REFERENCES[1] E. E. Aftandilian, S. Z. Guyer, M. Vechev, and

E. Yahav. Asynchronous assertions. In Proc. ofOOPSLA), pages 275–288, 2011.

[2] K. Beck and E. Gamma. Test infected: Programmerslove writing tests. Java Report, 3(7), July 1998.

[3] K. Boos, C.-L. Fok, C. Julien, and M. Kim. Brace: Anassertion framework for debugging cyber-physicalsystems. In Proc. of ICSE (NIER), pages 1341–1344,2012.

[4] J. Burnim and K. Sen. Asserting and checkingdeterminism for multithreaded programs. In Proc. ofESEC/FSE, pages 3–12, 2009.

[5] Q. Cao, T. Abdelzaher, J. Stankovic, K. Whitehouse,and L. Luo. Declarative tracepoints: A programmableand application independent debugging system forwireless sensor networks. In Proc. of SenSys, pages85–98, 2008.

[6] F. Chen, M. D’Amorim, and G. Rosu. A formalmonitoring-based framework for software developmentand analysis. In Proc. of ICFEM, volume 3308 ofLNCS, pages 357 – 373. Springer-Verlag, 2004.

[7] L. A. Clarke and D. S. Rosenblum. A historicalperspective on runtime assertion checking in softwaredevelopment. SIGSOFT Softw. Eng. Notes, 31:25–37,May 2006.

[8] R. Cleaveland, S. A. Smolka, and S. T. Sims. Aninstrumentation-based approach to controller modelvalidation. In Proc. of ASWSD, pages 84–97, 2008.

[9] S. Guo, Z. Zhong, and T. He. FIND: Faulty nodedetection for wireless sensor networks. In Proc. ofSenSys, pages 253–266, 2009.

[10] J.D.Valois. Lock-free linked lists usingcompare-and-swap. In Proc. of PODC, pages 214–222.ACM Press, 1995.

[11] G.-Y. Jin, X.-Y. Lu, and M.-S. Park. An indoorlocalization mechanism using active RFID tag. InProceedings of the IEEE International Conference onSensor Networks, Ubiquitous, nand TrustworthyComputing, 2006.

[12] M. Khan, H. Le, H. Ahmadi, T. Abdelzaher, andJ. Han. Dustminer: Troubleshooting interactivecomplexity bugs in sensor networks. In Proc. ofSenSys, pages 99–112, 2008.

[13] V. Krunic, E. Trumpler, and R. Han. NodeMD:Diagnosing node-level faults in remote wireless sensorsystems. In Proc. of MobiSys, pages 43–56, 2007.

[14] G. T. Leavens, A. L. Baker, and C. Ruby. Preliminarydesign of JML: A behavioral interface specificationlanguage for Java. Technical Report TR 98-06i, June1998.

[15] X. Liu, M. Corner, and P. Shenoy. Ferret: RFIDlocalization for pervasive multimedia. In Proc. ofUbicomp, pages 422–440, 2006.

[16] L. Luo, T. He, G. Zhou, T. Abdelzaher, andJ. Stankovic. Achieving repeatability of asynchronousevents in wireless sensor networks with EnviroLog. InProc. of INFOCOM, 2006.

[17] J. Mercadal, Q. Enard, C. Consel, and N. Loriant. Adomain-specific approach to architecturing errorhandling in pervasive computing. In Proc. ofOOPSLA, pages 47–61, 2010.

[18] Pharos: The pervasive computing test bed.http://mpc.ece.utexas.edu/pharos, 2011.

[19] N. Priyantha, A. Chakraborty, and H. Balakrishnan.The Cricket location-support system. In Proc. ofMobiCom, 2000.

[20] M. Quigley, K. Conley, B. P. Gerkey, J. Faust,T. Foote, J. Leibs, R. Wheeler, and A. Y. Ng. ROS:An open-source robot operating system. In ICRAWorkshop on Open Source Software, 2009.

[21] N. Ramanathan, K. Chang, R. Kapur, L. Girod,E. Kohler, and D. Estrin. Sympathy for the sensornetwork debugger. In Proc. of SenSys, pages 255–267,2005.

[22] U. Raza, A. Camerra, A. L. Murphy, T. Palpanas, andG. P. Picco. What does model-driven data acquisitionreally achieve in wireless sensor networks. In Proc. ofPercom), pages 85–94, 2012.

[23] K. Romer and J. Ma. PDA: Passive distributedassertions for sensor networks. In Proc. of IPSN, pages337–348, 2009.

[24] R. Sasnauskas, O. Landsiedel, M. Alizai, C. Weise,S. Kowalewski, and K. Wehrle. KleeNet: Discoveringinsidious interaction bugs in wireless sensor networksbefore deployment. In Proceedings of the 9th

ACM/IEEE International Conference on InformationProcessing in Sensor Networks (IPSN), pages 186–196,2010.

[25] T. Sookoor, T. Hnat, P. Hooimeijer, W. Weimer, andK. Whitehouse. Macrodebugging: Global views ofdistributed program execution. In Proc. of SenSys,2009.

[26] J. Weng, P. Cohen, and M. Herniou. Cameracalibration with distortion models and accuracyevaluation. IEEE Trans. Pattern Anal. Mach. Intell.,14:965–980, Oct. 1992.

[27] K. Whitehouse, G. Tolle, J. Taneja, C. Sharp, S. Kim,J. Jeong, J. Hui, P. Dutta, and D. Culler. Marionette:Using RPC for interactive development and debuggingof wireless embedded networks. In Proc. of IPSN,2006.

[28] J. Yang, M. Soffa, L. Selavo, and K. Whitehouse.Clairvoyant: A comprehensive source-level debuggerfor wireless sensor networks. In Proc. of SenSys, 2007.