Content uploaded by A. Benjamin Hocking
Author content
All content in this area was uploaded by A. Benjamin Hocking on Jan 29, 2021
Content may be subject to copyright.
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∈ ℜ | x≥0}(1)
R≡ {r∈ ℜ | r≥0∧r·r=x}(2)
The formal specification for the second subsystem is:
P≡ {y, z ∈ ℜ | z̸= 4}(3)
R≡ {r2∈ ℜ | r2=y/(z−4)}(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:
P≡factor ̸= 0 (5)
R≡smoothed =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 ≤y≤up. 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:
P≡v̸= 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].
a)
wheel speed
vehicle speed
apply brakes
ABS_Controller_supplier
b)
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.