{'fraction_non_alphanumeric': 0.02445324608231445, 'fraction_numerical': 0.02606050169335859, 'mean_word_length': 4.508061966487512, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Verification of Cyberphysical Systems

The value of verification of cyberphysical systems depends on the relationship between the 1 state of the software and the state of the physical system. This relationship can be complex because 2 of the real-time nature and different timelines of the physical plant, the sensors and actuators, and 3 the software that is almost always concurrent and distributed. In this paper, we study different 4 ways to construct a transition system model for the distributed and concurrent software components 5 of a CPS. We describe a logical-time based transition system model, which is commonly used for 6 verifying programs written in synchronous languages, and derive the conditions under which such a 7 model faithfully reflects physical states. When these conditions are not met (a common situation), 8 a finer-grained event-based transition system model may be required. We propose an approach 9 for formal verification of cyberphysical systems using Lingua Franca, a language designed for 10 programming cyberphysical systems, and Rebeca, an actor-based language designed for model 11 checking distributed event-driven systems. We focus on the cyber part and model a faithful interface 12 to the physical part. Our method relies on the assumption that the alignment of different timelines 13 during the execution of the system is the responsibility of the underlying platforms. We make those 14 assumptions explicit and clear. 15

configurations. We believe that no simple approach exists for verification of cyberphysical systems. 134 Several complimentary methods need to be used to cover the analysis of different aspects of such 135 systems, and in each method we rely on certain assumptions that may be guaranteed by other methods. 136 In a shorter conference paper version of this paper [19], we raise the interesting questions involved 137 in verification of cyberphysical systems and we used a couple of examples to show how we move 138 towards solving some of the problems. Here we explain the problem and the solutions in a more 139 extensive and structured way using mostly the same examples. The paper is organized as follows. 140 Section 2 introduces the programming model we assume (reactors) and the language in which programs 141 are written (Lingua Franca, LF). It sketches the source code in LF for a running example, a train door 142 controller. Section 3 introduces the Rebeca language and its timed extension, Timed Rebeca, which

152
Software components are called "reactors." The messages exchanged between reactors have logical 153 timetags drawn from a discrete, totally ordered model of time. Any two messages with the same 154 timetag are logically simultaneous, which means that, for any reactor with these two messages as 155 inputs, if it sees that one message has occurred, then it will also see that the other has occurred. 156 Moreover, every reactor will react to incoming messages in timetag order. If the reactor has reacted to 157 a message with timetag t, no future reaction in the same reactor will see any message with a lesser 158 timetag.

159
If a reactor produces output messages in reaction to an input, then, by default, the logical time 160 of the output will be identical to the logical time of the input. This principle is borrowed from 161 synchronous languages [20]. The Lingua Franca compiler ensures that all logically simultaneous 162 messages are processed in precedence order, so the computation is deterministic. At a logical instant, 163 the semantics of the program can be given as a unique least fixed point of a monotonic function on a 164 lattice [21], so the computation is deterministic, even if it is distributed across a network. We call this 165 semantics, based on the semantics of synchronous languages, the "logical-time-based semantics." Here, 166 we also consider an event-based semantics, which becomes useful when an interleaved execution of 167 events with the same logical timetag becomes observable. Event-based semantics has finer granularity 168 compared to logical-time-based semantics. 169 The syntax of a subset of Lingua Franca is given in Figure 1. The model consists of a set of reactors 170 and a main reactor. Reactors contain state variables, input and output ports, physical actions and 171 reactions. The body of reactions can be written in the target language. As of this writing, LF supports 172 C, C++, and TypeScript. In each case, the LF compiler generates a standalone executable in the target 173 language. A reactor may also react to a "physical action," which is typically triggered by some external 174 event such as a sensor [11]. The physical action will be assigned a timetag based on the current physical 175 clock on the machine hosting the reactor.

176
A key semantic property of Lingua Franca is that every reactor reacts to events in timetag order.

177
Preserving this order in a distributed execution is a key challenge. One technique that has proven effective is Ptides [22], a decentralized and fault-tolerant coordination mechanism that relies on Lingua Franca includes a notion of a deadline, which is a relation between logical time and 182 physical time, as measured on a particular platform. Specifically, a program may specify that the 183 invocation of a reaction must occur within some physical-time interval of the logical timestamp of 184 the message. This, together with physical actions, can be used to ensure some measure of alignment 185 between logical time and some measurement of physical time. ). The syntax is written in a slightly revised version of Extended BNF where instead of putting terminals in quotations we use words in "bold" format. Angled brackets ... are used as meta parenthesis, superscript + for repetition at least once, superscript * for repetition zero or more times, whereas using ... with repetition denotes a comma separated list. Brackets [...] indicates that the text within the brackets is optional. In the syntax, targetLanguageName, reactorName, mainReactorName stand for the target language for LF, the name of the reactor, and the name of the main reactor, respectively. The varId, typeId, inputId, outputId, actionId stand for the names of a variable, a type, an input and an output, respectively; and id stands for the name of an instance of a reactor. Target-Language-Statement stands for the statements of the target language. In the Reactor rule the components do not need to come in the presented order.

187
Consider a train door that needs to be locked before the train starts moving. The software 188 controlling train systems is able to lock the door and then send a command to the train to start moving.

189
Consider in Figure 2b the sketch of an implementation of a highly simplified version of such train 190 controller software in Lingua Franca. In this use, the code shown in the figure gets translated into C few. All will raise similar issues to those we address in this paper.

195
The structure of the code is illustrated in Figure 2a. It consists of three components called 196 "reactors," instances of the reactor classes Controller, Door, and Train. The main reactor (starting on 197 line 30) instantiates and connects these components so that the controller sends a messages to both the 198 door and the train. These components could be implemented on a single core, on multiple cores, or on 199 separate processors connected via a network.

200
Let's focus first on the interaction between these components and the physical world. The

201
Controller reactor class defines a physical action named "external_move" (line 5), which in Lingua   Franca is an event that is triggered by something outside the software system and is then assigned a 203 logical timetag that approximates the physical time at which that something occurred in the physical 204 world [11]. In practice, in the reaction(startup) block of code (starting on line 6), which executes 205 upon startup of the system, the reactor could set up an interrupt service routine (ISR) to be invoked 206 whenever the driver pushes a button to make the door lock and train move. The ISR would call an LF action (starting on line 9) will be invoked when logical time reaches the assigned timetag. This reaction (called message server) in an atomic and non-preemptive way. While executing a method, messages   Constructor

after(t)][deadline(t)]
Main ::= main { InstanceDcl * } InstanceDcl ::= className rebecName ( rebecName * ):( literal * ); Figure 3. Syntax of Timed Rebeca (adapted from [30]). The notation is the same as that in Figure 1. Identifiers className, rebecName, methodName, queueLength, v, literal, and type denote class name, rebec name, method name, queue length, variable, literal, and type, respectively; and e denotes an (arithmetic, boolean or nondetermistic choice) expression. In the instance declaration (rule InstanceDcl), the list of rebec names ( rebecName * ) passed as parameters denotes the known rebecs of that instance, and the list of literals ( literal * ) denotes the parameters of its constructor. stimulus at different times. If this value is changed from the previous period (comparing moveP and 257 oldMoveP on line 13) then the two message servers lock and move are called to lock (or unlock) the   Table 1 shows the mapping between Reactors and Timed Rebeca (extended with priorities). Each 262 reactor in Lingua Franca is mapped to a reactive class, and each reaction is mapped to a message server 263 in Rebeca. The trigger in a reaction is the name of the message server, and states in LF are mapped to 264 state variables in Rebeca. Rebeca is an object-based language, not a component-based one. Actors call 265 each other instead of writing on a port. In Lingua Franca we build the bindings between inputs and 266 outputs explicitly in the connection part of the program. In LF a reaction reacts to a trigger, and the 267 trigger is one of the inputs to the reactor. A reaction has outputs and those outputs are set by assigning 268 values to them. Then in the connection part of the main reactor, all the bindings are set by defining 269 which input of which reactor is connected to which output of which reactor. This way the flow of data 270 is realised. You can change the topology by changing the connections. In Rebeca, a message server of 271 other rebecs (or self) is called, and that is how the binding and the flow is realised. There is also a list 272 of known rebecs in a reactive class that shows the rebecs to whom you may send messages to.

273
For the timing issues, there is an after keyword in Lingua Franca that has the same semantics as annotations to both message servers and rebecs. The precedence graphs in LF cannot necessarily be of precedence graphs to a Rebeca model in the main can be done with no difficulty and is considered 284 as a future work. 285 We can also describe part of the mapping using the structure diagram in Figure 2a. The triangle 286 with the "P" is the physical action in LF and external message server in Rebeca, the circle is the 287 "startup" event in LF and the message sent in the constructor message server in Rebeca, the V-shape 288 arrows are reactions in LF and message servers in Rebeca, and the red arrows between the reactions 289 (message servers) are dependencies in LF, and priorities in Rebeca.

290
The mapping between Reactors and Timed Rebeca is natural and can easily be done. In Lingua 291 Franca we can write the body of reactions in any target language that LF supports. In this work we 292 write the body of reactions in Rebeca. After the code is model checked and debugged, then the Rebeca 293 code needs to be translated to one of the languages supported by LF to be able to execute the LF 294 program. Many design problems can be revealed by model checking the abstract model when the 295 complicated target code is not yet in place. We can also consider mapping the target codes to Rebeca, 296 that is left for the future work. To perform verification formally, we need to build a state-transition model of the program. Figure   309 4b gives the logical-time-based semantics of the program in Figure 2b. In the initial state, the door 310 is unlocked and the train is not moving. This state transition system shows that at each logical time,  It is not uncommon to design control system hardware precisely to make such guarantees. moving. This can be posed as a formal verification problem, where the goal is to prove this property.

357
In the program shown in Figure 2b, the door and train components have state variables, and we can 358 attempt to verify that the door is never in the unlocked state while the train is in the moving state.

359
Depending on how the physical interfaces are realized, however, this may or may not align with the 360 physical world. We can use the features of Lingua Franca to assure that the state of the software system 361 and the state of the physical world are aligned.

362
We can use Afra model checking tool to get the event-based state transition system of the Rebeca 363 model in Figure2c and to check safety properties. The event-based transition system is shown in Figure  S1_0:    from S6_0 to S7_0 and back, and S1_0 to S3_0 and back in Figure 4a.

369
The transition system of Figure 4a is a slightly revised version of the transition system generated 370 automatically by Afra. In this transition system, the state labeled "S4_0" violates our safety requirement.

371
The train is moving and the door is unlocked. There is a safe trace, going through S5_0 instead of 372 S4_0, but the interleaving semantics allows either trace. Similarly, the state labeled "S10_0" is also not       Figure 5b. Note that here we put different values for after constructs comparing to the LF code in Figure 5b.      door can only be locked if the door is closed. Here we assume that there is an open button for the 437 passengers also. So, a passenger can press the open button before the door is locked. The controller 438 sends the close and then the lock command, but there is a scenario in which the external open button is 439 pressed quickly enough that the door can never be locked, and consequently the train can never move. 440 We can change the values of the after construct for different commands and see various behaviors 441 of the system for different configurations. With the configuration shown in Figure 7 the door will never 442 be locked. We checked the assertion of door being unlocked and it is satisfied in this scenario showing 443 that the door stays unlock all the time. If we increase the value of after in sending external_open it 444 will eventually be large enough to allow the door to close and then lock.  Although Rebeca language, which is similar to Java, is expressive enough, it is not clear whether it  Because the Timed Rebeca code will be used for model checking, we need to be careful regarding 476 the state space explosion. The external method calls can be problematic here, and the Timed Rebeca 477 models may have to be carefully crafted in some places. The logical time intervals over which these 478 methods can be called has a great effect on the state space size. If the state space gets too large, model 479 checking becomes intractable.

480
Although we performed the mapping from Lingua Franca to Timed Rebeca by hand, it should be 481 possible to create a Rebeca target for Lingua Franca and then automate the translation. When using 482 this target, the body of each reaction will need to be written in Rebeca's own language for writing 483 message servers. This is necessary because Afra analyzes this code to build the transition system model, and as for now Afra is not capable of analyzing arbitrary C, C++, or TypeScript code, the target 485 languages currently supported by Lingua Franca.

486
One subtle point in model checking of CPS that we presented is that we only checked how the 487 state of the program evolves in logical time, not how it evolves in physical time. Every model checking 488 tool that we know of assumes a single timeline, but our systems always have at least three. There is the 489 logical timeline of timestamps, and programs can be verified on this timeline, proving for example that 490 a safety condition is satisfied by a state trajectory evolving on this logical timeline. But in a concurrent 491 and distributed CPS, the state trajectory is also evolving along a physical Newtonian timeline, and our 492 proof says nothing about its safety on that timeline. Moreover, every clock that measures Newtonian 493 time will differ from every other clock that measures Newtonian time, so any constraints we impose 494 on execution based on such clocks may again lead to proofs of safety even though the physical system 495 is capable of entering unsafe states. Our approach in this paper is relying on a set of assumptions 496 mainly based on alignment of logical and physical time at the execution time.

497
When we assert that a design has been "verified" against a set of formal requirements, we need to 498 make every effort to make as clear as possible what are the assumptions about the physical system that 499 make our conclusions valid. There will always be assumptions, and in any real system deployment, 500 any assumption may be violated. There is no such thing as a provably correct system.