Conference PaperPDF Available

Proving Critical Properties of Simulink Models

Authors:
  • Dependable Computing
Proving Critical Properties of Simulink Models
Ashlie B. Hocking, M. Anthony Aiello, John C. Knight∗†, and Nikos Aréchiga
Dependable Computing, Charlottesville, VA
Email: {ben.hocking,tony.aiello,john.knight}@dependablecomputing.com
University of Virginia, Charlottesville, VA
Email: jck@virginia.edu
Toyota InfoTechnology Center, USA, Mountain View, VA
Email: narechiga@us.toyota-itc.com
Abstract—Modern cyber-physical systems place ever-
increasing reliance on high-assurance software. Recent
high-profile safety and security incidents directly attributable
to software point to a failure to develop sufficient assurance
of software correctness through verification and validation.
While formal methods provide techniques for proving that
critical safety and security properties hold for all inputs and
all execution paths, engineers typically rely on simulation and
testing — which can only establish the presence but not the
absence of defects. A key reason for the lack of application of
formal methods is the perception that they are difficult to learn
and to use. In previous work, we introduced Simulink2PVS, a
tool that converts SIMU LI NK models to the PVS specification
language. In this paper, we extend Simulink2PVS to translate the
checks associated with SIM UL INK assertion blocks to putative
theorems. This approach allows engineers to state critical
safety and security properties using SIMULINK assertion blocks,
which are immediately familiar to engineers with SIMULINK
experience. Engineers can then prove that the properties hold
for all inputs and all execution paths. As a result, the expressive
and analytic power of the engineer’s existing toolkit has been
greatly increased and engineers are able to greatly enhance
their confidence in the assurance provided by the software.
I. INTRODUCTION
In this paper, we present a technique for defining critical
safety and security properties of SIMULINK models using
elements of the SIMULINK language. This ensures that critical
property definitions are located conveniently and defined using
a notation familiar to domain engineers. These critical prop-
erties become putative theorems of the model when combined
with a formal semantic definition of SIMULINK. Proving these
theorems allows engineers to have assurance that the properties
hold.
High-assurance software is critical for modern cyber-
physical systems. There have been many high-profile safety
and security incidents and accidents across all domains, from
automobiles to aircraft to medical devices to consumer de-
vices. Many of these incidents and accidents are directly
attributable to errors in software.
Demonstrating required levels of assurance through testing
is insufficient. Unless the input space of the software is exhaus-
tively sampled, testing is only able to establish the presence of
flaws — not the absence of flaws. For all but the most trivial
software units, it is infeasible to gain sufficient confidence in
software correctness for high levels of required dependability
through testing [1]. As a result, testing is unable to provide
adequate assurance of safety and security for modern cyber-
physical systems.
Nevertheless, such assurance is essential: engineers must
demonstrate that critical safety and security properties are
true for their systems. Formal, mathematical proof offers an
approach to establishing this assurance, by demonstrating that
properties are true in all possible situations — equivalent
to running all possible test cases. Proofs are possible with
formal methods, which combine languages providing formal
semantics with theorem provers or model checkers.
Most engineers are not familiar with formal methods. There
is a widespread belief that formal methods are difficult to
apply, and unfamiliarity and perceptions of difficulty pose
barriers to adoption. To overcome this burden, the formal
methods community has sought to enable engineers to state
properties using common modeling paradigms. This approach
allows engineers to document critical safety and security
properties of the models explicitly, which are translated into
putative theorems that are the target of proofs.
Engineers developing software using model-based design in
languages such as SIMULINK commonly use assertion blocks
to state conditions they believe to be true about their models.
During simulation of the model, falsification of the condition
feeding into the assertion block causes the simulation to halt
and the engineer to be notified. When executable code is
generated from the model, assertion blocks and dedicated logic
are removed.
The conditions expressed by assertion blocks range in
complexity from simple bounds checks to more rigorous and
complex expressions that may form the basis for safety and
security properties. These properties are open-loop properties
that focus on the behavior of the control software without
consideration of the dynamics of the surrounding system.
When coupled with domain-relevant analyses, these open-
loop properties can be used to establish critical closed-loop
properties of the system.
The use of assertion blocks provides important documen-
tation of properties that engineers believe to be true about
their models. Additionally, assertion blocks are easy to use
and, because they operate during simulation, allow some
defects to be detected very early in the development cycle.
Unfortunately, like testing, assertion blocks can typically only
establish the presence of flaws: simulation of the software is
rarely exhaustive and therefore seldom establishes the absence
of flaws.
We have developed an approach for proving that the prop-
erties represented by assertion blocks hold for all possible
inputs and for all time steps. Our approach enables engineers
to document critical safety and security properties without
learning a new language and then to prove that the properties
are true. This approach is based on translating SIMULINK
models to the PVS specification language [2], including the
properties represented by assertion blocks. Using our ap-
proach, engineers can not only document critical safety and
security properties, but also prove that they are true at design
time. In effect, we have increased the power of the tools
available to practicing engineers by extending the assertion
block from simply checking properties during simulation to
generating putative theorems that can be proven using PVS.
II. FO RMAL SPECI FICATION
Software specifications state as completely as possible what
the result of a computation must be, ideally without stat-
ing how the computation should be performed. Similarly, in
model-based design, engineers describe a computation using
primitives provided by the modeling language, ideally without
concern for how the primitives will be implemented on the tar-
get machine. Model-based design can therefore be viewed as
producing the specification for the computation, while the code
generator can be viewed as producing the implementation.
Formal software specifications are typically written using
pre-conditions and post-conditions. This approach was orig-
inally described by Hoare and is typically referred to as a
Hoare triple [3]. A Hoare triple has the form: P{Q}R,
where Pis the pre-condition, Ris the post-condition, and
Qis a computation such as a program function. The triple
states: if Pis true before the computation, then Rwill be true
after the computation.
When formal software specifications are combined with
formal semantics for program execution, proofs of partial
correctness are possible. In particular, software can be proved
to conform to its specification. The specification can then be
freely substituted for the software itself as documentation of
program behavior. Additionally, critical functional and non-
functional properties that are separate from the functional
specification can be stated as putative theorems of the specifi-
cation. Proving these putative theorems demonstrates that the
program behavior satisfies the functional and non-functional
properties.
In model-based design, primitives provided by the mod-
eling language should come with pre-conditions and post-
conditions that document formally the semantics of the be-
havior specified by the model. Unfortunately, many popular
model-based-design languages, such as SIM ULINK, do not
have an established formal semantics. Instead, the specified
behavior is informally documented using natural language and
an operational semantics is used: the precise semantics of the
model are those implied by the generated implementation.
In previous work, we introduced Simulink2PVS, a tool that
translates a SIMULINK model into a PVS specification [4],
[5]. PVS provides both a powerful specification language as
well as a powerful theorem prover with which proofs of prop-
erties including non-linear arithmetic can be established. In
developing Simulink2PVS, we are incrementally establishing
formal semantics for supported SIMULINK blocks and their
parameters. Currently, Simulink2PVS supports 127 parameters
related to 63 SIMULINK blocks, as well as support for a subset
of embedded MATLAB code. In a related, parallel effort, we
are actively working to refine and expand the formal semantics
for SIM ULINK, which we intend to publish for the community
at a later date. The current formal semantics provides a target
for proofs of partial correctness and putative theorems.
The formal semantics we are establishing are for SIMULINK
itself and are not tied to the generated implementation. Proper-
ties and proofs of properties are therefore established directly
for the models and are not tied to details of the generated
implementation. Reasoning across significantly different levels
of abstraction is generally difficult: just as programmers used
to working in a high-level language find it difficult to reason
about properties at the level of the generated assembly code, so
domain engineers used to working with properties in the model
find it difficult to reason about the generated implementation.
Establishing proofs of properties directly for the model
enables domain engineers to continue to realize the benefit of
model-based development. Domain engineers are freed from
irrelevant details of how the computation will be carried out by
digital computers, while those details that are relevant are com-
municated explicitly through the formal semantics. Moreover,
by establishing properties of the model, domain engineers are
strengthening the specification of program behavior. Finally,
when used in conjunction with a code generator targeting
a high-level programming language with established formal
semantics, such as the SPARK subset of Ada [6], proofs
of partial correctness are possible using approaches such as
Echo [7], [8]. Critical properties established directly for the
SIMULINK model can therefore be proven to be maintained in
the generated implementation.
As an example of a critical property, consider an automobile
cruise-control system. The functionality of the system is
derived from control theory and specified as the behavior of the
software in response to vehicle dynamics and input from the
automobile controls. Additionally, the engineers might wish
to show that the cruise-control system can never command
acceleration when the brake pedal is pressed — a critical
safety property. This critical property must hold irrespective
of vehicle dynamics and other actions taken by the driver.
Typically, critical properties of this form are stated outside
of the specification and are translated into putative theorems
during program verification and validation. However, much
like the pre-conditions and post-conditions that form the
specification of functional behavior, these critical properties
are important documentation of functional and non-functional
requirements. Separating these properties from the model is
undesirable for two important reasons: (1) if the model is
changed in such a way that requires refinement of the property,
engineers may overlook the inconsistency when the properties
are stated separately from the model; and (2) the utility of
the properties as documentation of requirements is diminished
when the properties are stated separately from the model.
Our approach allows engineers to state critical proper-
ties in the model, using SIMULINK assertion blocks. Using
Simulink2PVS, we translate these properties into putative
theorems. The formal semantics for SIMULINK provided by
Simulink2PVS provides a foundation upon which proofs of
putative theorems can be completed. By proving critical prop-
erties about the model, engineers can have greater confidence
that the model is correct.
III. APPROACH
Our approach to encoding properties in SIMULINK models
is designed:
1) to be easy to read and write;
2) to be immediately familiar to engineers with SIMULINK
experience;
3) to support formal proof.
Fig. 1. Square Root to Biased Divide
Figure 1 illustrates a simple SIM ULINK model in which two
subsystems are connected: the first subsystem computes the
square root of its input, x; the second subsystem divides its
first input yby its second input, z, biased by negative four.
The formal specification for the first subsystem is:
P≡ {x∈ ℜ | x0}(1)
R≡ {r∈ ℜ | r0r·r=x}(2)
The formal specification for the second subsystem is:
P≡ {y, z ∈ ℜ | z̸= 4}(3)
R≡ {r2∈ ℜ | r2=y/(z4)}(4)
To correctly compose these two subsystems, the result of
the square root must at least satisfy the pre-condition z̸= 4.
Thus, a critical property of the composition is that r̸= 4.
Using our approach, this property is introduced by way of an
assertion block connected to a test that the output of the square
root is not equal to four.
This property will only hold if the input to the square root
is not 16. Thus another property of the composition is that
x̸= 16. As above, this property is introduced by way of an
assertion block connected to a test that the input to the square
root is not equal to 16.
Figure 2 shows both of these properties. The assertion
blocks have been highlighted for clarity.
It is clear from this example that our first two design goals
have been met. Since the properties are stated with common
Fig. 2. Square Root Example with Properties
SIMULINK blocks, engineers with SIM ULINK experience find
them to be immediately familiar. This familiarity ensures that
the properties are very easy to read and write.
Simulink
Application
Model
PVS Theories for
Application
Model
Simulink2PVS
PVS Verification System
Human
Guidance
Application
Critical
Properties
Simulink
Assertion
Blocks
PVS Rep. of
Application
Properties
Results
Application
Required
Functionality
Simulink
Formal
Semantics
Libraries Of
Strategies &
Theories
Fig. 3. Simulink2PVS
The SIMULINK model, including any properties stated using
assertion blocks, is translated to the PVS specification lan-
guage using Simulink2PVS, as shown in Figure 3. Using the
formal semantics of SIMULINK that it defines, Simulink2PVS
generates a formal specification of the functional behavior of
the SIMULINK model. The specification takes the form of a set
of PVS theories, which group type definitions together with the
pre-conditions and post-conditions associated with each sup-
ported SIM ULINK primitive block. Similarly, using the formal
semantics of SIMULINK that it defines, Simulink2PVS gen-
erates Boolean-valued functions that represent the properties
stated using assertion blocks. Simulink2PVS then generates a
putative theorem for each property, asserting that the property
is true.
The formal specification and all of the properties are first
type checked using the PVS theorem prover. Type checking
detects a variety of errors, including failure to meet the pre-
condition of a SIMULINK block, which indicates an error in
the software. After type checking is complete, each property is
proved using the PVS theorem prover. The proof is monitored
and possibly guided by a human expert. Successful proof of
the theorem establishes that the property holds over all valid
inputs.
IV. ILL USTRATI VE EXAMPLES
To illustrate our approach, we have developed three ex-
amples. The first two examples illustrate the inclusion of
properties that constrain the functionality of a computation.
The final example illustrates the inclusion of critical safety
properties.
When formal specifications are given in this section, all
variables are assumed to be real numbers.
A. Smoothing Calculation
A simple subsystem for smoothing a varying signal is shown
in Figure 4b. The formal specification of the subsystem is:
Pfactor ̸= 0 (5)
Rsmoothed =prior + 1/f actor ·(new prior)(6)
a)
b)
Smoothing
Fig. 4. a) Smoothing Subsystem and Properties; b) Details of Smoothing
Subsystem
A desired property of the use of this subsystem might be
that when the signal is changing, the variance be reduced,
rather than magnified. Formally, that is, new ̸=prior =
|smoothed prior|<|new prior|. Similarly, when the
signal is not changing, there should be no variance. Formally,
that is, new =prior =smoothed =prior Using
our approach, these properties are introduced with assertions,
as shown in Figure 4a, where they are labeled Consequent:
Smoothing and Consequent: No Change, respectively.
The smoothing property will not hold if the smoothing
factor is less than or equal to one, so an additional property
is needed that factor > 1. Using our approach, this property
is introduced with an assertion, as shown in Figure 4a, where
it is labeled Antecedent: Factor Greater Than One.
B. Dynamic Saturation
The SIMULINK primitive dynamic-saturation block is shown
in Figure 5.
max
value result
min
Fig. 5. Dynamic Saturation Block and Properties
This primitive block has no pre-condition. Its post-
condition, in pseudocode, is:
if u > up then
y = up
else if u < lo then
y = lo
else
y = u
end if
Close examination of the post-condition of this block reveals
potentially surprising behavior should the limits cross — that
is, should up become less than lo. A desired property of
the use of this block might therefore be that the output yis
always between the two limits, up and lo. Formally, that is,
lo yup. Using our approach, this property is introduced
with an assertion, as shown in Figure 5, where it is labeled
Consequent: Result In Between.
This property will always hold unless lo is not less than up,
so an additional property is needed. Using our approach, this
property is introduced with an assertion, as shown in Figure 5,
where it is labeled Antecedent: Max Not Less Than Min.
C. Error Calculation
A simple subsystem for computing the relative error be-
tween two signals is shown in Figure 6b.
a)
b)
Error Calc
requested
force
calculated
force
relative error
Fig. 6. a) Error Subsystem and Property; b) Details of Error Subsystem
The formal specification for the subsystem is:
Pv̸= 0 (7)
Rη=
vˆv
v
(8)
The subsystem is used in a model to check that a compu-
tation has been performed correctly by computing the relative
error between a requested force and a calculated force. In
this model, a critical safety property is that the calculated
force not deviate from the requested force by more than
one percent. Formally, that is, error 0.01. Using our ap-
proach, this property is introduced with an assertion, as shown
in Figure 6a, where it is labeled Consequent: Acceptable
Relative Error.
V. CAS E STUDY
In this section, we present a case study of the approach
based on a simple automotive application. For completeness,
we include some of the details of the formal specification
of the safety property of interest and the resulting putative
theorem. Recall that engineers will typically not need to review
or interact with the PVS specification and properties that
are generated by Simulink2PVS. We anticipate that a pro-
duction implementation of the approach will provide suitable
application-level support.
A simple controller for an antilock brake system (ABS)
is shown in Figure 7b. This controller is derived from one
provided by MathWorks [9], with the controller logic separated
from the plant logic, as discussed in previous work [4], [5].
In this model, it is assumed that the driver of the auto-
mobile has depressed the brake pedal and intends to bring
the automobile to a stop. The role of the ABS controller is
to ensure that the wheel speed does not deviate significantly
from the vehicle speed, as such a deviation indicates that the
wheels have locked or may soon lock. The ABS controller
wheel speed
vehicle speed
apply brakes
a)
b)
ABS_Controller_oem
Fig. 7. a) ABS Controller and Property; b) Details of the Controller
prevents excessive deviation by releasing the brakes. When
the deviation in wheel speed from vehicle speed becomes
acceptable, the brakes are reengaged.
Under the assumption that the driver has depressed the brake
pedal, a critical safety property of the controller is that the
brakes remain engaged when the automobile comes to a stop.
Formally, that is, speedv ehicle =brakesapplied . Using
our approach, this property is introduced with an assertion, as
shown in Figure 7a, where it is labeled Consequent: Applies
Brakes When At Rest.
Simulink2PVS translates the assertion into PVS, using a
Boolean function:
Consequent_Applies_Brake_When_At_Rest(
p_sys: sys_type,
p_Wheel_Speed: real,
p_Vehicle_Speed: real): bool =
At_Rest(p_Vehicle_Speed)
IMPLIES Compare_To_Constant(
run(p_sys, p_Wheel_Speed,
p_Vehicle_Speed
)‘f_output‘f_Apply_Brakes);
Simulink2PVS then asserts that the function is true, using a
putative theorem:
Theorem_Applies_Brake_When_At_Rest: THEOREM
FORALL(sys: sys_type, wheel_speed: real,
vehicle_speed: real):
Consequent_Applies_Brake_When_At_Rest(
sys, wheel_speed, vehicle_speed);
Unfortunately, there is an error in the design of this controller
and the proof of the putative theorem expressing the safety
property cannot be completed. Unless the wheel speed is
non-zero when the automobile stops, the controller releases
the brakes. That is, with the brake pedal pressed, when the
vehicle comes to a stop, the ABS controller releases the brakes
irrespective of the driver’s intent. Clearly, this is not what is
intended. The required condition, stated as a property of the
system and introduced with an assertion, is shown in Figure 7a,
where it is labeled Antecedent: Non-Zero Wheel Speed.
Simulink2PVS translates the assertion into PVS, using a
Boolean function:
Antecedent_Non_Zero_Wheel_Speed(
p_sys: sys_type,
p_Wheel_Speed: real,
p_Vehicle_Speed: real): bool =
Compare_To_Eps(p_Wheel_Speed);
The putative theorem is then restated, using this assertion as
an assumption to help prove the desired property.
Theorem_Applies_Brake_When_At_Rest: THEOREM
FORALL(sys: sys_type, wheel_speed: real,
vehicle_speed: real):
Antecedent_Non_Zero_Wheel_Speed(
sys, wheel_speed, vehicle_speed)
IMPLIES
Consequent_Applies_Brake_When_At_Rest(
sys, wheel_speed, vehicle_speed);
With this assumption, the proof can be completed.
Of course, this assumption is clearly unacceptable. It does
not make sense for the controller to apply the brakes only if
the wheels are turning, while the automobile is at rest. The
controller design is flawed.
An alternative controller design for the ABS is shown
in Figure 8b. This controller has been proven to behave
identically to the controller shown in Figure 7b, except when
the automobile is stopped [4].
Fig. 8. a) Alternative ABS Controller and Property; b) Details of the
Alternative Controller
Although the design of the controller has changed, the
assumptions in the model have remained the same. As such,
the safety property described above applies: that the brakes
remain engaged when the automobile comes to a stop. Using
our approach, this property is introduced with an assertion, as
shown in Figure 8a, where it is labeled Consequent: Applies
Brakes When At Rest.
This controller design does not contain the error observed
above. As such, the proof of the putative theorem expressing
the safety property can be completed, establishing that the
safety property holds for all inputs.
VI. RE LATED WORK
A. Reactis Validator
Reactis Validator provides engineers with tools for stating
assertions for SIMULINK models [10]. The Validator tool au-
tomatically searches for violations of the property [11]. When
a violation is found, a counterexample is produced in the form
of a test case. The violation search is designed to efficiently
generate complete modified condition/decision coverage (MC/
DC) coverage while eliminating redundancy [12].
Reactis Validator differs from our approach in two important
ways. First, assertions are stated in a separate file and associ-
ated with the model using Reactis. Properties are important
documentation about the model; separating them from the
model limits their utility. Second, assertions are not proven;
instead, test cases are generated to look for property violations.
MC/DC coverage is an important and useful metric, but is not
a substitute for proof when establishing a critical safety or
security property.
B. Formal Verification Tools
VerSÅA is a tool for proving that SIMULINK models and
MATLAB code adhere to formal contracts [13], [14]. Ver-
SÅA represents SIMULINK models as synchronous data-flow
graphs; properties are stated formally using higher-order logic
and are attached to the data-flow graphs. Proofs are completed
using Z3, an SMT solver.
Chen et al. present a toolchain for proving properties of
SIMULINK models [15]. Their approach automatically trans-
lates SIMULINK models to Timed Interval Calculus, which
is automatically translated to the PVS specification language.
Properties are stated formally in either Timed Interval Calculus
or PVS. Proofs are completed using the PVS theorem prover.
ClawZ is a tool that allows the user to prove properties
and partial correctness of the generated implementation of
a SIMULINK model [16]. ClawZ translates SIMULINK to Z
specifications; properties are stated in Z as putative theorems
of the specification. Proofs are completed using ProofPower,
a theorem prover.
Our approach differs from all three of these approaches by
enabling engineers to state properties directly in SIMULINK,
rather than using a new language. Familiarity with the property
language removes a critical barrier to adoption of formal
methods.
AutoCert extends the verification capabilities provided by
ClawZ to prove low-level properties of the generated imple-
mentation, such as potential array-bounds violations [17]. The
focus of AutoCert’s analysis is the generated implementation,
not the original SIMULINK model. Proving partial correctness
of the generated implementation is important, but orthogonal
to the approach discussed here: proofs of partial correctness
establish that the implementation matches the specification, but
do not establish the presence of critical high-level safety and
security properties. Our approach enables domain engineers to
prove these critical properties.
C. Simulink Design Verifier
Simulink Design Verifier (SLDV) provides engineers with
tools that facilitate test-case generation, dead-code identifica-
tion, and static analysis of simple type-correctness properties,
such as division by zero [18]. Additionally, SLDV allows
engineers to identify cases in which assertions might fail
using bounded model checking or k-induction. Bounded model
checking exhaustively searches for property falsification over
bounded, finite-length execution paths. k-induction attempts to
infer an invariant over some number of steps and then verify
satisfaction of the invariant.
Unfortunately, some of the details of SLDV are unclear
because rigorous documentation of the technology does not
appear to be publicly available. Informal documentation ex-
ists, but it is difficult to validate SLDV’s claims of formal
verification. Moreover, the lack of available formal semantics
for SIM ULINK results in a lack of clarity as to what SLDV
verifies.
In the context of software assurance for critical safety and
security properties, lack of available, rigorous documentation
and informality makes establishing required assurance diffi-
cult. The ability to scrutinize analysis tools is of paramount
importance if engineers are to be confident that verification
results are valid.
SLDV differs from our approach in four important ways.
First, we use a theorem prover to establish that properties
hold over all inputs and all execution paths of arbitrary length.
Second, although it is incomplete, we are defining a formal se-
mantics for SIMULINK and using that formal semantics as the
basis for all of our verification. Third, the PVS specification for
the functional behavior of the SIMULINK model, including all
of the translated properties, is available for scrutiny. Finally,
PVS is a well-documented and thoroughly studied theorem
prover. Our reliance on PVS greatly increases confidence in
the correctness of our verification results.
VII. CONCLUSION
Many high-profile safety and security incidents and acci-
dents of cyber-physical systems have been directly attributable
to errors in software. The practical application of formal
methods to model-based design provides engineers with tools
to establish needed assurance of software correctness, bridging
the gap between verification tools and engineering design
tools. We have developed an approach to documenting for-
mally critical safety and security properties in SIMULINK
using assertion blocks. Our approach is easy to read and
write, is immediately familiar to engineers with SIMULINK
experience, and supports formal proof. Using our approach,
engineers can detect and fix defects early in the development
process, both increasing software assurance and decreasing
development cost.
Currently, the approach is implemented as a research pro-
totype that is based on Simulink2PVS. Future work will
enhance the utility of the approach by providing engineers
with greater application support. This support will further
reduce the barriers to adoption of the approach by enabling
engineers to complete proofs of critical properties directly
within the SIMULINK environment. Additionally, future work
will develop additional PVS libraries and proof strategies,
accelerating and automating the proof process.
ACKNOWLED GMENT
The authors thank Toyota InfoTechnology Center, USA and
Toyota Motor Corporation for their support.
REFERENCES
[1] R. W. Butler and G. B. Finelli, “The infeasibility of experimental
quantification of life-critical software reliability,SIGSOFT Softw. Eng.
Notes, vol. 16, no. 5, pp. 66–76, Sep. 1991. [Online]. Available:
http://doi.acm.org/10.1145/123041.123054
[2] S. Owre, J. M. Rushby, and N. Shankar, “PVS: A prototype verification
system,” in 11th International Conference on Automated Deduction
(CADE), ser. Lecture Notes in Artificial Intelligence, D. Kapur, Ed.,
vol. 607. Saratoga, NY: Springer-Verlag, jun 1992, pp. 748–752.
[3] C. A. R. Hoare, “An axiomatic basis for computer programming,
Communications of the ACM, vol. 12, no. 10, pp. 576–580, 1969.
[4] A. B. Hocking, J. Knight, M. Aiello, and S. Shiraishi, “Proving model
equivalence in model based design,” in Software Reliability Engineering
Workshops (ISSREW), 2014 IEEE International Symposium on, Nov
2014, pp. 18–21.
[5] A. B. Hocking, J. C. Knight, M. A. Aiello, and S. Shiraishi, “Formal
verification in model based development,” SAE Technical Paper, Tech.
Rep., 2015.
[6] P. Amey, “Correctness by construction: Better can also be cheaper,
CrossTalk: the Journal of Defense Software Engineering, vol. 2, pp.
24–28, 2002.
[7] X. Yin, J. Knight, E. Nguyen, and W. Weimer, “Formal verification by
reverse synthesis,Computer Safety, Reliability, and Security, pp. 305–
319, 2008.
[8] X. Yin, “Echo: Practical formal verification by reverse synthesis,” Ph.D.
dissertation, University of Virginia, 2012.
[9] “Modeling an anti-lock braking system.”
[10] Reactive Systems, Inc., “Achieving ISO 26262 compliance with Reac-
tis,” June 2012.
[11] ——, “Reactis validator.” [Online]. Available: http://www.reactive-
systems.com/reactis/doc/user/user009.html
[12] R. Cleaveland, S. Sims, and D. Hansel, “System and method for
automatic test-case generation for software,” Patent. [Online]. Available:
http://patents.justia.com/patent/20050160321
[13] P. Boström, R. Grönblom, T. Huotari, and J. Wiik, “An approach
to contract-based verification of simulink models,” TUCS Technical
Report, Tech. Rep., October 2010.
[14] J. Wiik and P. Boström, “Contract-based verification of matlab and
simulink matrix-manipulating code,” in Formal Methods and Software
Engineering. Springer, 2014, pp. 396–412.
[15] C. Chen, J. S. Dong, and J. Sun, “Machine-assisted proof support
for validation beyond Simulink,” in Formal Methods and Software
Engineering. Springer, 2007, pp. 96–115.
[16] F. Zeyda and A. Cavalcanti, “Mechanised translation of control law
diagrams into circus,” in Integrated Formal Methods. Springer, 2009,
pp. 151–166.
[17] E. Denney and S. Trac, “A software safety certification tool for automat-
ically generated guidance, navigation and control code,” in Aerospace
Conference, 2008 IEEE. IEEE, 2008, pp. 1–11.
[18] J.-F. Etienne, S. Fechter, and E. Juppeaux, “Using Simulink Design
Verifier for proving behavioral properties on a complex safety critical
system in the ground transportation domain,” in Complex Systems Design
& Management. Springer, 2010, pp. 61–72.
... Safety-critical systems are often developed using modelbased tools, such as MathWorks Simulink ® , in which models are created using a custom notation via a graphic interface. A model can be examined using simulation, executable code for the model can be synthesized, test cases can be generated for the model, and the model can be checked with a static analyser [1] [2]. ...
... Safety properties of interest are application specific and are included in Simulink models as Assertion blocks [2]. Sim-ulink2PVS recognizes Assertion blocks in models and translates them into PVS theorems. ...
Conference Paper
Full-text available
Model-based development of software using tools such as MathWorks Simulink has become common in the engineering of safety-critical systems. When working with Simulink, engineers need to be able to assure that the subject models possess crucial properties such as: (1) safety properties are met, (2) the use of measurement units is consistent, (3) freedom from exceptions, (4) the execution sequences of blocks is as planned, and (5) data types are inferred properly. In this paper, we describe: (a) an approach to the graphic decoration of Simulink models to display information determined by formal verification, and (b) a system, SimulinkDec, that implements the decoration. Block colouring, enhancements to block textual descriptions, and comments are used to present the information of interest to the user. SimulinkDec provides a graphical user interface that allows engineers to easily perform formal verification and display the results of that analysis.
... Overall, Alloy ensures the correctness and reliability of software systems and detects and fixes potential errors early in the design process, leading to higher-quality software that is easier to maintain and update over time [29]. SIMULINK has been used as a tool for the modelling and verification of complex systems [30]. SCADE [31], and Papyrus-RT [32] are some of the other frameworks and environments developed for formal modelling and verification in different fields. ...
... This may be done using a system like SPARK [8], for example, when traditional software engineering is followed. In model-based design, this may be done using a tool like Simulink2PVS [9], [10], [11], [12], [13] or SLDV [14]. ...
Technical Report
Full-text available
This report examines the role of assume-guarantee reasoning in compositional analysis. We propose clearer terminology for assume-guarantee reasoning, to facilitate talking about the compositional-analysis role as compared to the component-analysis role. We identify a key limitation in assume-guarantee reasoning for compositional analysis and discuss ways in which the limitations may be addressed.
... We applied our approach to a Simulink model for an example adaptive cruise control system in which the DVFs are represented as lookup tables (LUTs). The approach, which relies on our Simulink2PVS tool [2], yields a 67,000% speedup as compared to sequential proof of the 74,170 proof cases. ...
Conference Paper
Full-text available
Real-world applications often include large, empirically defined discrete-valued functions. When proving properties about these applications, the proof naturally breaks into one case per entry in the first function reached, and again into one case per entry in the next function, and continues splitting. This splitting yields a combinatorial explosion of proof cases that challenges traditional proof approaches. While each proof case represents a mathematical path from inputs to outputs through these functions, the full set of cases is not available up front, preventing a straightforward application of parallelism. Here we describe an approach that slices the input space, creating a partition based on pre-computed mathematical paths such that each slice has only a small number of proof cases. These slices are amenable to massively parallel proof. We evaluate this approach using an example model of an adaptive cruise control, where proofs are conducted in a highly parallel PVS environment.
Thesis
The growing share of driver assistance functions, their criticality, as well as the prospect of certification of these functions, make their verification and validation necessary with a level of requirement that testing alone cannot ensure. For several years now, other industries such as aeronautics and railways have been subject to equivalent contexts. To respond to certain constraints, they have locally implemented formal methods. We are interested in the motivations and criteria that led to the use of formal methods in these industries in order to transpose them to automotive scenarios and identify the potential scope of application.In this thesis, we present our case studies and propose methodologies for the use of formal methods by non-expert engineers. Inductive model checking for a model-driven development process, abstract interpretation to demonstrate the absence of run-time errors in the code and deductive proof for critical library functions.Finally, we propose new algorithms to solve the problems identified during our experiments. These are, firstly, an invariant generator and a method using the semantics of data to process properties involving long-running timers in an efficient way, and secondly, an efficient algorithm to measure the coverage of the model by the properties using mutation techniques.
Conference Paper
Full-text available
Software verification is a critical component of software development. Software verification techniques include different forms of testing, inspection, static analysis, and formal verification. Formal verification offers the advantage that it corresponds, at least informally, to testing all possible paths through the software. There are two primary approaches to using formal verification to establish properties of software: (a) proving properties of a formal specification, and (b) proving an implementation is a refinement of its specification. The first approach allows inference of the proven properties of the implementation provided the implementation is correct. The second approach allows inference of the correctness of the implementation. Proving properties of a specification provides a means for detecting critical design flaws early in the development process. In model-based development, the model (e.g., a set of SIMULINK diagrams) is a formal specification of the desired system. Thus, formal methods can be applied to such models to gain the advantage of early defect detection. The technique we have developed begins by synthesizing a formal specification of a SIMULINK model in the PVS specification language. Once the model has been converted to PVS, standard theorems that characterize the basic type and consistency rules of SIMULINK are proved using the PVS verification system. Once the standard theorems are proved, theorems describing crucial properties (especially those related to safety) of the subject system are stated and proved. To demonstrate the utility and feasibility of our approach, we analyzed a hypothetical ABS controller model, based on a model provided by MathWorks.
Conference Paper
Full-text available
We introduce the concept of constrained equivalence of models in model-based development and present a proof technology for establishing constrained equivalence for models documented in Math Works Simulink. We illustrate the approach using a simple model of an automobile anti-lock braking system.
Conference Paper
Full-text available
Model-based' design and automated code generation are being used increasingly at NASA. Many NASA projects now use MathWorks Simulink and Real- Time Workshop for at least some of their modeling and code development. The trend is to move beyond simulation and prototyping to actual flight code, particularly in the Guidance, Navigation, and Control domain. However, there are substantial obstacles to more widespread adoption of code generators in such safety-critical domains. Since code generators are typically not qualified, there is no guarantee that their output is correct, and consequently the generated code still needs to be fully tested and certified. Moreover, the regeneration of code can require complete recertification, which offsets many of the advantages of using a generator. Indeed, manual review of autocode can be more challenging than for hand-written code. Since the direct V&V of code generators is too laborious and complicated due to their complex (and often proprietary) nature, we have developed a generator plug-in to support the subsequent certification of the code that is generated. Specifically, the AutoCert tool supports certification by formally verifying that the generated code is free of different safety violations, by constructing an independently verifiable certificate, and by explaining its analysis in a textual form suitable for code reviews. This enables missions to obtain assurance about the safety and reliability of the code without excessive manual V&V effort and, as a consequence, increases the acceptance of code generators in safety-critical contexts. The generation of explicit certificates and textual reports is particularly well-suited to supporting independent V&V. The key technical idea of our approach is to exploit the idiomatic nature of auto-generated code in order to automatically infer logical annotations. These allow the automatic formal verification of the safety properties without requiring access to the inter- nals of the code generator. The approach is independent of the particular generator used but is currently being adapted to code generated using MathWorks Real-Time Workshop, an automatic code generator that translates from Simulink/Stateflow models into embedded C code.
Conference Paper
Full-text available
Simulink is popular in industry for modeling and simulating embedded systems. It is deflcient to handle requirements of high-level assurance and timing analysis. Previously, we showed the idea of ap- plying Timed Interval Calculus (TIC) to complement Simulink. In this paper, we develop machine-assisted proof support for Simulink models represented in TIC. The work is based on a generic theorem prover, Prototype Veriflcation System (PVS). The TIC speciflcations of both Simulink models and requirements are transformed to PVS speciflca- tions automatically. Veriflcation can be carried out at interval level with a high level of automation. Analysis of continuous and discrete behav- iors is supported. The work enhances the applicability of applying TIC to cope with complex Simulink models.
Conference Paper
This paper presents an approach to automatic, modular, contract-based verification of programs written in a subset of the MATLAB programming language, with focus on efficiently handling the provided matrix manipulation functions. We statically infer types and shapes for matrices in the language and use this information in the verification. We consider two approaches for verification: direct axiomatisation of the built-in matrix functions and expansion of the functions. We evaluate our approaches on a number of examples and discuss challenges for automatic verification in this setting.
Conference Paper
We present our return of experience in using Simulink Design Verifier for the verification and validation of a safety-critical function. The case study concerns the train tracking function for an automatic train protection system (ATP). We basically show how this function is formalized in Simulink and present the various proof strategies devised to prove the correctness of the model w.r.t. high-level safety properties. These strategies have for purpose to provide a certain harness over time/memory consumption during proof construction, thus avoiding the state space explosion problem.
Conference Paper
In this paper we describe a novel yet practical approach to the for- mal verification of implementations. Our approach splits verification into two major parts. The first part verifies an implementation against a low-level specification written using source-code annotations. The second extracts a high-level specification from the implementation with the low-level specifi- cation, and proves that it implies the original system specification from which the system was built. Semantics-preserving refactorings are applied to the implementation in both parts to reduce the complexity of the verification. Much of the approach is automated. It reduces the verification burden by dis- tributing it over separate tools and techniques, and it addresses both function- al correctness and high-level properties at separate levels. As an illustration, we give a detailed example by verifying an optimized implementation of the Advanced Encryption Standard (AES) against its official specification.
Conference Paper
Previously we proposed a strategy for translating control law diagrams into Circus. Combining elements from Z, CSP, and a renement calculus, Circus captures functional and dynamic aspects of a diagram, and allows us to formally verify implementations. The main contributions of this paper are rst to discuss a generalisation of the existing translation strat- egy, motivated by its mechanisation and application to sizable examples. Secondly, we present a tool, the Circus Producer, which automates the translation, and describe how its architecture facilitates subsequent de- velopment of further verication tools.