Tải bản đầy đủ - 0 (trang)
2 Use Case 2: Runtime Monitors for Lab Evaluation

2 Use Case 2: Runtime Monitors for Lab Evaluation

Tải bản đầy đủ - 0trang

Applying Runtime Monitoring for Automotive Electronic Development


Post-SI Verification Support

UC1: Runtime

Lab Evaluation

Time Invariant



Offline Monitoring


Formalized System

Properties in STL


System Evaluation

STL Formula Sets

STL Validation



Realization on a

specific HW platform

High-level Synthesis

HW Runtime

Monitors Generation

HW Runtime

Monitors TopLevel


STL Temporal

Operators Modeling


Temporal Operators

Lib C++

UC2: Runtime

Monitoring in SIM


Temporal Operators

Lib C++

Fig. 2. Runtime monitoring generation flow

The key concept of use case 2 is to synthesize the monitors from use case 1

into FPGAs, to be used as an extended lab-equipment support for lab evaluation

activities. This is especially true for the scenarios in which errors can be seen

only after a certain test time. For example, hardware runtime errors, or scenarios

including large amounts of data exchange between sensor and ECU. The aim

is to guarantee that the implementation satisfies the requirements, under its

operational condition, and sometimes under a stress condition.

In this use case runtime monitors are synthesized in an FPGA and run in

parallel with the test hardware to keep up with the real-time sensor-ECU data

exchange requirements. The C++ code (“synthesizable” in Fig. 2) is supplied to

High-Level Synthesis [18] to generate RTL that can be put in FPGA. To be able

to obtain efficient hardware implementation the code must use hardware precise

data types and must not dynamically allocate memory.


Case Study: Automotive Sensor Interface

This section describes the runtime monitoring, both in simulation and in hardware, of the magnetic sensor used in electronic power steering (Fig. 1).

We monitor the temporal requirements of the communication protocol (PSI5)

between the sensor and the ECU. To demonstrate our approach we build STL

monitors for checking the shape of the data and synchronization pulses. The

ECU sends synchronization pulse to the sensor via the voltage line. The sensor

produces the reply by modulating the current. We monitor both, the voltage from


K. Selyunin et al.

Signal 1

Signal 2

Signal 3




Signal 1














Signal 8



Signals 7-12, 13

Signal 9

Signal 10

Signal 11

Signal 12

Signal 13

Fig. 3. The runtime monitor in simulation: setup and results

the ECU and the current from the sensor: raise and fall time of these pulses must

not exceed trise . These requirements can be written in the past-STL:

rise req:

fall req:

enter(high) → trans S [0,trise ] exit(low)

enter(low) → trans S [0,trise ] exit(high),

where enterϕ and exitϕ are syntactic sugar for ¬ϕ ∧ ϕ and ϕ ∧ ¬ϕ.

Figure 3 shows the simulation setup and the result of a run of the chip model.

A magnetic field - Signal 1 in Fig. 3 - is supplied to the sensor. Then the field

values are sampled by an ADC and passed through a filter for internal processing

in a sensor, Signals 2–4. After powering the chip and a passed stabilization

time, the ECU sends synchronization pulses to the sensor (Signal 5, Fig. 3). In

synchronization mode, each synchronization pulse sent by the ECU is responded

by modulated sensor frames: Signal 6. Signals 7–12 in Fig. 3 are intermediate

outputs of the sub-formula of the specification “rise req” (“fall req” is omitted

from the picture for conciseness). Signal 13 is the output of the monitor, which,

in this case, indicates that the requirement has been met.

To demonstrate the second use case, we generate the runtime monitors in

FPGA and check the test chip. Figure 4 illustrates the lab setup: To emulate

the ECU we use a signal generator that sends synchronization pulses to the

test chip. The sensor replies with data packets, which are handled by an Analog

Front-End (AFE). In the FPGA the transmission line between the sensor and the

ECU is modeled (Fig. 1) to facilitate an evaluation of various system integration

scenarios. We generate hardware monitors using Vivado HLS and integrate them

to the output of the transmission line, where we check the same requirements as

in the chip simulation (i.e. “req rise”). We use the Xilinx debug core to observe

the communication between the sensor and the ECU and the outputs of our

monitors on the ChipScope (Fig. 5).

Applying Runtime Monitoring for Automotive Electronic Development









Sync pulse)










Line Emulator®

Fig. 4. Runtime monitor in hardware: lab setup

Fig. 5. Runtime monitor in hardware: chip scope results




K. Selyunin et al.


In this paper we proposed and illustrated the two use cases of runtime monitoring

in the automotive electronic development, and demonstrated their usefulness by

checking the communication interface requirements of a steering-wheel magnetic

sensor. We showed that runtime monitors can be included in a chip-concept

simulation and that they can be later reused for requirements-monitoring inthe-lab after applying High Level Synthesis. Runtime monitoring in automotive

electronic industry promises to speed up the verification process and can be

considered as an additional tool to capture runtime bugs which could be very

challenging to catch by classical in-the-lab approaches.

Acknowledgment. This research is supported by the project HARMONIA (845631),


funded by a national Austrian grant from FFG (Osterreichische



ungsgesellschaft) under the program IKT der Zukunft and the EU ICT COST Action

IC1402 on Runtime Verification beyond Monitoring (ARVI).


1. Kolbe, M., Schoo, J.: Industry overview the automotive electronics industry in

Germany. Germany Trade and Invest (2014)

2. ISO 26262: road vehicles Functional safety. International Organization for Standardization (ISO) (2011)

3. Okuda, R., Kajiwara, Y., Terashima, K.: A survey of technical trend of adas and

autonomous driving. In: Proceedings of International Symposium on VLSI Design,

Automation and Test (VLSI-DAT) 2014, pp. 1–4, April 2014

4. Sans, M.: X-by-wire park assistance for electric city cars. In: Proceedings of World

Electric Vehicle Symposium and Exhibition (EVS27) 2013, pp. 1–9, November 2013

5. Infineon Technologies AG: Sensing the world: sensor solutions for automotive,

industrial and consumer applications. Infineon Technologies AG (2016)

6. Leucker, M.: Teaching runtime verification. In: Khurshid, S., Sen, K. (eds.) RV

2011. LNCS, vol. 7186, pp. 34–48. Springer, Heidelberg (2012)

7. Niˇckovi´c, D., Piterman, N.: From Mtl to deterministic timed automata. In:

Chatterjee, K., Henzinger, T.A. (eds.) FORMATS 2010. LNCS, vol. 6246, pp.

152–167. Springer, Heidelberg (2010)

8. Maler, O., Nickovic, D., Pnueli, A.: From MITL to timed automata. In: Asarin,

E., Bouyer, P. (eds.) FORMATS 2006. LNCS, vol. 4202, pp. 274–289. Springer,

Heidelberg (2006)

9. Pnueli, A., Zaks, A.: On the merits of temporal testers. In: Grumberg, O., Veith,

H. (eds.) 25 Years of Model Checking. LNCS, vol. 5000, pp. 172–195. Springer,

Heidelberg (2008)

10. Jaksic, S., Bartocci, E., Grosu, R., Kloibhofer, R., Nguyen, T., Nickovic, D.: From

signal temporal logic to FPGA monitors. In: Proceedings of 13 ACM/IEEE International Conference on Formal Methods and Models for Codesign, pp. 218–227


11. Geist, J., Rozier, K.Y., Schumann, J.: Runtime observer pairs and Bayesian network reasoners on-board FPGAs: flight-certifiable system health management for

embedded systems. In: Bonakdarpour, B., Smolka, S.A. (eds.) RV 2014. LNCS, vol.

8734, pp. 215–230. Springer, Heidelberg (2014). doi:10.1007/978-3-319-11164-3 18

Applying Runtime Monitoring for Automotive Electronic Development


12. Reinbacher, T., Fă

ugger, M., Brauer, J.: Runtime verification of embedded real-time

systems. Formal Meth. Syst. Des. 44(3), 203–239 (2014)

13. Nguyen, T., Niˇckovi´c, D.: Assertion-based monitoring in practice–checking correctness of an automotive sensor interface. In: Lang, F., Flammini, F. (eds.) FMICS

2014. LNCS, vol. 8718, pp. 16–32. Springer, Heidelberg (2014)

14. Nguyen, T., Wooters, S.N.: FPGA-based development for sophisticated automotive

embedded safety critical system. SAE Int. J. Passeng. Cars Electron. Electr. Syst.

7, pp. 125–132 (2014)

15. Nguyen, T., Basa, A., Hammerschmidt, D., Dittfeld, T.: Advanced mixed-signal

emulation for complex automotive ICs. In: AIRBAG Conference, pp. 1–8 (2014)

16. Donz´e, A., Maler, O., Bartocci, E., Nickovic, D., Grosu, R., Smolka, S.: On temporal logic and signal processing. In: Chakraborty, S., Mukund, M. (eds.) ATVA

2012. LNCS, vol. 7561, pp. 92–106. Springer, Heidelberg (2012)

17. Maler, O., Nickovic, D., Pnueli, A.: On synthesizing controllers from boundedresponse properties. In: Damm, W., Hermanns, H. (eds.) CAV 2007. LNCS, vol.

4590, pp. 95–107. Springer, Heidelberg (2007)

18. Vivado High-Level Synthesis. http://www.xilinx.com/products/design-tools/

vivado/integration/esl-design.html. Accessed 25 May 2016

Regular Tool Papers

A Monitoring Tool for a Branching-Time Logic

Duncan Paul Attard(B) and Adrian Francalanza

CS, ICT, University of Malta, Msida, Malta


Abstract. We present the implementation of an experimental tool that

automatically synthesises monitors from specifications written in mHML,

a monitorable subset of the branching-time logic μHML. The synthesis

algorithm is compositional wrt the structure of the formula and follows

closely a synthesis procedure that has been shown to be correct. We discuss how this compositionality facilitates a translation into concurrent

Erlang monitors, where each individual (sub)monitor is an actor that

autonomously analyses individual parts of the source specification formula while still guaranteeing the correctness of the overall monitoring




Runtime Verification (RV) is a lightweight verification technique that compares

the execution of a system against correctness specifications. Despite its advantages, this technique has limited expressivity and cannot be used to verify arbitrary specifications such as (general) liveness properties [6]. These limits are

further explored in [3] wrt. the branching-time domain for a logic called μHML,

describing properties about the computational graph of programs. The work identifies a syntactic logical subset called mHML, and shows it to be monitorable

and maximally-expressive wrt. the constraints of runtime monitoring.

This paper discusses the implementation of a prototype tool that builds on

the results of [3]. A pleasant by-product of these results is the specification of a

synthesis procedure that generates correct monitor descriptions from formulas

written in mHML. Our tool investigates the implementability of this synthesis

procedure, instantiating it to generate executable monitors for a specific generalpurpose programming language. This instantiation follows closely the procedure

described in [3], thereby giving us higher assurances that the generated executable monitors are indeed correct. Furthermore, we exploit the compositional

structure of the procedure in [3] and refine the synthesis so as to enable it

to produce concurrent monitors wherein (sub)monitors autonomously analyse

individual parts of the global specification formula while still guaranteeing the

correctness of the overall monitoring process. Through our tool, we show how

these concurrent components can be naturally mapped to Erlang [2] actors that

monitor a running system with minimal instrumentation efforts.

This work was partly supported by the project “TheoFoMon: Theoretical Foundations for Monitorability” (nr.163406-051) of the Icelandic Research Fund.

c Springer International Publishing AG 2016

Y. Falcone and C. Sanchez (Eds.): RV 2016, LNCS 10012, pp. 473–481, 2016.

DOI: 10.1007/978-3-319-46982-9 31


D.P. Attard and A. Francalanza

This paper is structured as follows. Section 2 reviews the logic and synthesis

procedure from [3]. Subsequently, Sect. 3 presents changes by which this synthesis procedure can achieve higher detection coverage. The challenges encountered

while implementing a synthesis procedure that follows closely the formal description developed in Sect. 3, are discussed in Sect. 4. Finally, Sect. 5 concludes and

briefly reviews related work.



The syntax of ψ ∈ mHML, a monitorable subset of μHML, is given in Fig. 1.

It consists of two syntactic classes, sHML, describing invariant properties, and

cHML, describing properties that hold eventually after a finite number of events.

The logical formula [α]θ states that for all system executions producing event

α (possibly none), the subsequent system state must then satisfy θ, whereas the

formula α π states that there exists a system execution with event α whereby

the subsequent state then satisfies π. E.g., [α]ff describes systems that cannot

produce event α, whereas α tt describes systems that can produce event α.

max X.θ and min X.π resp. denote maximal and minimal fixpoints for recursive

Fig. 1. The logic mHML, the monitor syntax, and compositional synthesis function

A Monitoring Tool for a Branching-Time Logic


formulas; these act as binders for X in θ (resp. π), where we work up to αconversion of bound variables while assuming recursive formulas to be guarded.


Monitors are expressed as a standard process calculus where m −−→ m

denotes a monitor in state m observing event α and transitioning to state m . The

action τ denotes internal transitions while μ ranges over α and τ . For instance,



m1 + m2 denotes an external choice where m1 + m2 −−→ m if either m1 −−→ m


or m2 −−→ m (Fig. 1 omits the symmetric rule). The only novelty is the use

of verdicts v: persistent states that do not change when events are analysed,

modelling the irrevocability of a verdict v (see [3] for details).

The synthesis function − from mHML formulas to monitors is also given

in Fig. 1. Although the function covers both sHML and cHML, the syntactic

constraints of mHML mean that synthesis for a formula ψ uses at most the first

row (i.e., the logical constructs common to sHML and cHML) and then either

the first column (in the case of sHML) or the second column (in case of cHML).

It is worth noting that the monitor synthesis function is compositional wrt. the

structure of the formula, e.g., the monitor for ψ1 ∧ ψ2 is defined in terms of the

submonitors for the subformulas ψ1 and ψ2 . Finally, we highlight the fact that

conditional cases used in the synthesis of conjunctions, disjunctions, necessity

and possibility formulas, and maximal and minimal fixpoints are necessary to

handle logically equivalent formulas and generate correct monitors.

Example 1. The sHML formula ϕ1 describes the property stating that “after

any sequence of service requests (req) and responses (ans), a request is never

followed by two consecutive responses”, i.e., subformula [ans][ans]ff. The synthesis

function in Fig. 1 translates ϕ1 into the monitor process m1 .

ϕ1 = max X. [req]([ans]X ∧ [ans][ans]ff )

m1 = rec x. req.(ans.x + ans.ans.no)

ϕ2 = min X. ping X ∨ cls tt ∨ (min Y.ff ∨ cls ff )

m2 = rec x. ping.x + cls.yes

The cHML formula ϕ2 describes a property where after a (finite) sequence of

ping events, the system closes a channel connection cls. The subformula min Y.ff∨

cls ff is semantically equivalent to ff; accordingly the side conditions in Fig. 1

take this into consideration when synthesising monitor m2 .

Note that although the synthesis employs both acceptance and rejection verdicts, it only generates uni-verdict monitors that only produce acceptances or

rejections, never both; [3] shows that this is essential for monitor correctness.


Refining the Monitor Synthesis

The first step towards implementing our tool involved refining the existing synthesis function to improve monitor detections. Specifically, there are cases where

the synthesis function in Fig. 1 produces monitors with non-deterministic behaviour. For instance, monitor m1 of Example 1 may exhibit the following behaviour:



rec x.req. ans.x + ans.ans.no −→ · −−→ ans.m1 + ans.ans.no


D.P. Attard and A. Francalanza

at which point, upon analysing action ans, it may non-deterministically transition to either m1 or ans.no. The latter case can raise a rejection if it receives

another ans event but the former case, i.e., m1 , does not — this results in a

missed detection. Although this behaviour suffices for the theoretical results

required in [3], it is not ideal from a practical standpoint. The problem stems

from a limitation in the choice construct semantics, m1 + m2 , which forces a

selection between submonitor m1 or m2 upon the receipt of an event.

We solve this problem by replacing external choice constructs with a parallel

monitor composition construct, m1 ×m2 that allows both submonitors to process

the event without excluding one another. The semantics of the new combinator

is defined by the following rules (again we omit symmetric cases):

The first rule states that both monitors proceed in lockstep if they can process

the same action. The second rule states that if only one monitor can process the

action and the other is stuck (i.e., it can neither analyse action α, nor transition

internally using τ ), then the able monitor transitions while terminating the stuck

monitor. Otherwise, the monitor is allowed to transition silently by the third rule.

The last rule terminates parallel monitors once a verdict is reached.

We define a second synthesis function − by structural induction on the

formula. Most cases are identical to those of − in Fig. 1 with the exception of

the two cases below, substituting the choice construct for the parallel construct:

if ψ2 = yes

if ψ2 = no

⎨ ψ1

⎨ ψ1



ψ1 ∧ ψ2 =

if ψ1 = yes ψ1 ∨ ψ2 =

if ψ1 = no



ψ1 × ψ2 otherwise

ψ1 × ψ2 otherwise

The two monitor synthesis functions correspond in the sense of Theorem 1.

In [3], verdicts are associated with logic satisfactions and violations, and thus

Theorem 1 suffices to show that the new synthesis is still correct.





Theorem 1. For all ψ ∈ mHML, m −−1→ . . . −−n→ v iff m −−1→ . . . −−n→ v.

Proof. By induction on the strucure of ψ. Most cases are immediate because

the resp. translations correspond. In the case of ψ1 ∧ ψ2 where the synthesis




yields ψ1 + ψ2 , a verdict is reached only if ψ1 −−1→ . . . −−n→ v or ψ2 −−1→






. . . −−n→ v. By I.H. we obtain ψ1 −−1→ . . . −−n→ v (or ψ2 −−1→ . . . −−n→ v)



which suffices to show that ψ1 × ψ2 −−→ . . . −−→ v. A dual argument can

be constructed for the implication in the opposite direction.

Example 2. For ψ1 in Example 1, we now only have the following monitor behaviour:





rec x.req. ans.x × ans.ans.no −

→ · −→ ans.m1 × ans.ans.no −−→ m1 × ans.no −−→ no

A Monitoring Tool for a Branching-Time Logic




We implement a RV tool which analyses the correctness of concurrent programs

developed in Erlang. Actions, in the form of Erlang trace events, consist of two

types: outputs i ! d and inputs i ? d, where i corresponds to process (i.e., actor)

identifiers (PID), and d denotes the data payload associated with the action in

the form of Erlang data values (e.g., PID, lists, tuples, atoms, etc.). Specifications, defined as instantiations of mHML terms, make use of action patterns

which possess the same structure as that of the aforementioned actions, but

may also employ variables (alphanumeric identifiers starting with an uppercase

letter) in place of values; these are then bound to values when pattern-matched

to actions at runtime. Action patterns require us to synthesise a slightly more

general form of monitors with the following behaviour: if a pattern e matches a

trace event action α, thereby binding a variable list to values from α (denoted

as σ), the monitor evolves to the continuation m, substituting the variables in

m for the values bound by pattern e (denoted by mσ); otherwise it transitions

to the terminated process end.

match(e, α) = σ

match(e, α) = ⊥


e.m −−→ end

e.m −−→ mσ


mHML formulas are synthesised into Erlang code, following closely the synthesis function discussed in Sect. 3. In particular, we exploit the inherent concurrency features offered by Erlang together with the modular structure of the

synthesis to translate submonitors into independent concurrent actors [2] that

execute in parallel. An important deviation from the semantics of parallel composition specified in Sect. 3 is that actors execute asynchronously to one another.

For instance, one submonitor may be analysing the second action event whereas

another may forge ahead to a stage where it is analysing the fourth event. The

moment a verdict is reached by any submonitor actor, all others are terminated,

and said verdict is used to declare the final monitoring outcome. This alternative semantics still corresponds to the one given in Sect. 3 for three main reasons:

(i) monitors are univerdict, and there is no risk that one verdict is reached before

another thereby invalidating or contradicting it; (ii) processing is local to each

submonitor and independent of the processing carried out by other submonitors; (iii) verdicts are irrevocable and monitors can terminate once an outcome

is reached, safe in the knowledge that verdicts, once announced, cannot change.

Monitor recursion unfolding, similar to the work in [4], constitutes another

minor departure from the semantics in Sect. 3, as the implementation uses a

process environment that maps recursion variables to monitor terms. Erlang

code for monitor rec x.m is evaluated by running the code corresponding to the

(potentially open) term m (where x is free in m) in an environment with the

map x → m.

Figure 2 outlines the compilation steps required to transform a formula script

file (script.hml) into a corresponding Erlang source code monitor implementation (monitor.erl). To be able to adhere the compositional synthesis of Sect. 3

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

2 Use Case 2: Runtime Monitors for Lab Evaluation

Tải bản đầy đủ ngay(0 tr)