Practical Techniques for Verification and Validation of Robots - - PowerPoint PPT Presentation

▶

Oct 30, 2022 219 likes •709 views

Practical Techniques for Verification and Validation of Robots Kerstin Eder with a demo by Dejanira Araiza Illan University of Bristol and Bristol Robotics Laboratory Would you swallow a robot? The Safety Challenge Autonomous Systems

SLIDE 1

Practical Techniques for Verification and Validation of Robots

Kerstin Eder with a demo by Dejanira Araiza Illan

University of Bristol and Bristol Robotics Laboratory

SLIDE 2

Would you swallow a robot?

SLIDE 3

The Safety Challenge

§ Autonomous Systems § Engineering Challenge

– Advances in control science – Focus on “making things work”

SLIDE 4

4 Pictures from www.wikipedia.org

SLIDE 5

The Safety Challenge

§ Autonomous Systems § Engineering Challenge

– Advances in control science – Focus on “making things work”

§ Fundamental concern:

– Can such systems be trusted?

SLIDE 6

SLIDE 7

Dependability

§ A system is dependable (or trustworthy) only if it can be shown to be safe and useful.

– Safety is the property of avoiding harmful conditions. – Liveness requires that the system achieves its goals a.k.a. usefulness.

§ Demonstrable safety and liveness are required.

SLIDE 8

Safety Assurance

Assurance is the essential concept:

§ A system may never cause harm throughout its entire operating life, § but if we cannot be assured of that before we start to use it, then the system can not be trusted.

SLIDE 9

Designing Dependable Systems

§ Create flawless designs. AND § Design the system in such a way that the flawlessness can be demonstrated.

"Waterfall" by M.C Escher.

SLIDE 10

EPSRC “Principles of Robotics”

“Robots are products. They should be designed using processes which assure their safety and security.”

10 http://www.epsrc.ac.uk/ourportfolio/themes/engineering/activities/Pages/principlesofrobotics.aspx

SLIDE 11

To develop techniques and methodologies that can be used to design autonomous intelligent systems that are demonstrably trustworthy.

Verification and Validation for Safety in Robots

SLIDE 12

Correctness from specification to implementation

User Requirements

High-level Specification

Optimizer

Design and Analysis (Simulink)

Controller (SW/HW)

e.g. C, C++, RTL (VHDL/Verilog)

Translate Implement

SLIDE 13

What can be done at the code level?

P. Trojanek and K. Eder.

Verification and testing of mobile robot navigation algorithms: A case study in SPARK. IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS).

pp. 1489-1494. Sep 2014.

http://dx.doi.org/10.1109/IROS.2014.6942753

SLIDE 14

What can go wrong in robot navigation software?

Generic bugs:

§ Array and vector out-of-bounds accesses § Null pointer dereferencing § Accesses to uninitialized data

Domain-specific bugs:

§ Integer and floating-point arithmetic errors § Mathematic functions domain errors § Dynamic memory allocation errors § Concurrency bugs

§ blocking inter-thread communication (non real-time)

SLIDE 15

State of the art verification approaches

§ Model checking

§ infeasible for real (off-the-shelf) code

§ Static analysis of C++

§ not possible

§ Static analysis of C

§ requires verbose and difficult to maintain annotations

SLIDE 16

HW Design Reconvergence Model

Fabrication Specification Netlist Silicon Chip HW Design

SLIDE 17

SLIDE 18

HW Design Reconvergence Model

Fabrication Specification Netlist Silicon Chip HW Design Verification Test

§ Design Verification is the process used to gain confidence in the correctness of a design w.r.t. the requirements and specification. § Test: Manufacturing Test vs Functional Test

Tape out

SLIDE 19

Design-for-Test(ability)

http://anysilicon.com/overview-and-dynamics-of-scan-testing/

SLIDE 20

Design-for-Verification Approach

§ SPARK, a verifiable subset of Ada

§ software reliability a primary goal § no memory allocation, pointers, concurrency § side-effect free functions § SPARK specification and tools freely available for academic use

§ Required code modifications:

§ Pre- and post-conditions, loop (in)variants § Numeric subtypes (e.g. positive) § Formal data containers

SLIDE 21

Navigation in SPARK

§ Three open-source implementations of navigation algorithms translated from C/C++ (2.7 kSLOC) to SPARK (3.5 kSLOC)

Vector Field Histogram
Nearness Diagram
Smooth Nearness-Diagram

§ Explicit annotations are less than 5% of the code § SPARK code is on average 30% longer than C/C++

SLIDE 22

Verification Conditions

SLIDE 23

Formal Verification Results

Number of discharged verification conditions and the running time of static analysis

SLIDE 24

Results

§ Several bugs discovered by run-time checks injected by the Ada compiler

Fixed code proved to be run-time safe
except floating-point over- and underflows
These require the use of complementary techniques, e.g.

abstract interpretation.

§ Up to 97% of the verification conditions discharged automatically by SMT solvers in less than 10 minutes § Performance of the SPARK and C/C++ code similar

Moral: If you want to make runtime errors an issue

f the past, then select your tools (programming

language and dev env) wisely!

SLIDE 25

Moral

If you want to make runtime errors an issue of the past, then you must select your tools (programming language and dev env) wisely!

SLIDE 26

http://github.com/riveras/spark-navigation

P. Trojanek and K. Eder.

Verification and testing of mobile robot navigation algorithms: A case study in SPARK. IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS).

pp. 1489-1494. Sep 2014.

http://dx.doi.org/10.1109/IROS.2014.6942753

SLIDE 27

Correctness from Specification to Implementation

User Requirements

High-level Specification

Optimizer

Design and Analysis (Simulink)

Controller (SW/HW)

e.g. C, C++, RTL (VHDL/Verilog)

Translate Implement Verification

SLIDE 28

What can be done at the design level?

D. Araiza Illan, K. Eder, A. Richards.

Formal Verification of Control Systems’ Properties with Theorem Proving. International Conference on Control (CONTROL), pp. 244 – 249. IEEE, Jul 2014. http://dx.doi.org/10.1109/CONTROL.2014.6915147

D. Araiza Illan, K. Eder, A. Richards.

Verification of Control Systems Implemented in Simulink with Assertion Checks and Theorem Proving: A Case Study. European Control Conference (ECC), pp. tbc. Jul 2015. http://arxiv.org/abs/1505.05699

SLIDE 29

What is an assertion?

§ An assertion is a statement that a particular property is required to be true.

– A property is a Boolean-valued expression

§ Assertions can be checked either during simulation or using a formal property checker. § Assertions have been used in SW design for a long time.

– assert() function is part of C #include <assert.h> – Used to detect NULL pointers, out-of-range data, ensure loop invariants, etc.

§ Revolution through Foster & Bening’s OVL for Verilog.

– Clever way of encoding re-usable assertion library in Verilog. J – > 30 checker types (assertion templates) – http://accellera.org/activities/working-groups/ovl

SLIDE 30

SLIDE 31

SLIDE 32

TYPE NAME PARAMETERS PORTS DESCRIPTION

Single-Cycle assert_always #(severity_level, property_type, msg, coverage_level) (clk, reset_n, test_expr) test_expr must always hold Two Cycles assert_always_on_edge #(severity_level, edge_type, property_type, msg, coverage_level) (clk, reset_n, sampling_event, test_expr) test_expr is true immediately following the specified edge (edge_type: 0=no-edge, 1=pos, 2=neg, 3=any) n-Cycles assert_change #(severity_level, width, num_cks, action_on_new_start, property_type, msg, coverage_level) (clk, reset_n, start_event, test_expr) test_expr must change within num_cks of start_event (action_on_new_start: 0=ignore, 1=restart, 2=error) n-Cycles assert_cycle_sequence #(severity_level, num_cks, necessary_condition, property_type, msg, coverage_level) (clk, reset_n, event_sequence) if the initial sequence holds, the final sequence must also hold (necessary_condition: 0=trigger-on-most, 1=trigger-on-first, 2=trigger-on-first- unpipelined) Two Cycles assert_decrement #(severity_level, width, value, property_type, msg, coverage_level) (clk, reset_n, test_expr) if test_expr changes, it must decrement by the value parameter (modulo 2^width) Two Cycles assert_delta #(severity_level, width, min, max, property_type, msg, coverage_level) (clk, reset_n, test_expr) if test_expr changes, the delta must be >=min and <=max Single Cycle assert_even_parity #(severity_level, width, property_type, msg, coverage_level) (clk, reset_n, test_expr) test_expr must have an even parity, i.e. an even number of bits asserted Two Cycles assert_fifo_index #(severity_level, depth, push_width, pop_width, property_type, msg, coverage_level, simultaneous_push_pop) (clk, reset_n, push, pop) FIFO pointers should never overflow or underflow n-Cycles assert_frame #(severity_level, min_cks, max_cks, action_on_new_start, property_type, msg, coverage_level) (clk, reset_n, start_event, test_expr) test_expr must not hold before min_cks cycles, but must hold at least once by max_cks cycles (action_on_new_start: 0=ignore, 1=restart, 2=error) n-Cycles assert_handshake #(severity_level, min_ack_cycle, max_ack_cycle, req_drop, deassert_count, max_ack_length, property_type, msg, coverage_level) (clk, reset_n, req, ack) req and ack must follow the specified handshaking protocol Single-Cycle assert_implication #(severity_level, property_type, msg, coverage_level) (clk, reset_n, antecedent_expr, consequent_expr) if antecedent_expr holds then consequent_expr must hold in the same cyle Two Cycles assert_increment #(severity_level, width, value, property_type, msg, coverage_level) (clk, reset_n, test_expr) if test_expr changes, it must increment by the value parameter (modulo 2^width) Single-Cycle assert_never #(severity_level, property_type, msg, coverage_level) (clk, reset_n, test_expr) test_expr must never hold Single-Cycle assert_never_unknown #(severity_level, width, property_type, msg, coverage_level) (clk, reset_n, qualifier, test_expr) test_expr must never be an unknown value, just boolean 0 or 1 Combinatorial assert_never_unknown_async #(severity_level, width, property_type, msg, coverage_level) (reset_n, test_expr) test_expr must never go to an unknown value asynchronously, it must remain boolean 0 or 1 n-Cycles assert_next #(severity_level, num_cks, check_overlapping, check_missing_start, property_type, msg, coverage_level) (clk, reset_n, start_event, test_expr) test_expr must hold num_cks cycles after start_event holds Two Cycles assert_no_overflow #(severity_level, width, min, max, property_type, msg, coverage_level) (clk, reset_n, test_expr) if test_expr is at max, in the next cycle test_expr must be >min and <=max Two Cycles assert_no_transition #(severity_level, width, property_type, msg, coverage_level) (clk, reset_n, test_expr, start_state, next_state) if test_expr==start_state, in the next cycle test_expr must not change to next_state Two Cycles assert_no_underflow #(severity_level, width, min, max, property_type, msg, coverage_level) (clk, reset_n, test_expr) if test_expr is at min, in the next cycle test_expr must be >=min and <max Single-Cycle assert_odd_parity #(severity_level, width, property_type, msg, coverage_level) (clk, reset_n, test_expr) test_expr must have an odd parity, i.e. an odd number of bits asserted Single-Cycle assert_one_cold #(severity_level, width, inactive, property_type, msg, coverage_level) (clk, reset_n, test_expr) test_expr must be one-cold i.e. exactly one bit set low (inactive: 0=also-all-zero, 1=also-all-ones, 2=pure-one-cold) Single-Cycle assert_one_hot #(severity_level, width, property_type, msg, coverage_level) (clk, reset_n, test_expr) test_expr must be one-hot i.e. exactly one bit set high Combinatorial assert_proposition #(severity_level, property_type, msg, coverage_level) (reset_n, test_expr) test_expr must hold asynchronously (not just at a clock edge) Two Cycles assert_quiescent_state #(severity_level, width, property_type, msg, coverage_level) (clk, reset_n, state_expr, check_value, sample_event) state_expr must equal check_value on a rising edge of sample_event (also checked on rising edge of `OVL_END_OF_SIMULATION) Single-Cycle assert_range #(severity_level, width, min, max, property_type, msg, coverage_level) (clk, reset_n, test_expr) test_expr must be >=min and <=max n-Cycles assert_time #(severity_level, num_cks, action_on_new_start, property_type, msg, coverage_level) (clk, reset_n, start_event, test_expr) test_expr must hold for num_cks cycles after start_event (action_on_new_start: 0=ignore, 1=restart, 2=error) Two Cycles assert_transition #(severity_level, width, property_type, msg, coverage_level) (clk, reset_n, test_expr, start_state, next_state) if test_expr changes from start_state, then it can only change to next_state n-Cycles assert_unchange #(severity_level, width, num_cks, action_on_new_start, property_type, msg, coverage_level) (clk, reset_n, start_event, test_expr) test_expr must not change within num_cks of start_event (action_on_new_start: 0=ignore, 1=restart, 2=error) n-Cycles assert_width #(severity_level, min_cks, max_cks, property_type, msg, coverage_level) (clk, reset_n, test_expr) test_expr must hold for between min_cks and max_cks cycles Event-bound assert_win_change #(severity_level, width, property_type, msg, coverage_level) (clk, reset_n, start_event, test_expr, end_event) test_expr must change between start_event and end_event Event-bound assert_window #(severity_level, property_type, msg, coverage_level) (clk, reset_n, start_event, test_expr, end_event) test_expr must hold after the start_event and up to (and including) the end_event Event-bound assert_win_unchange #(severity_level, width, property_type, msg, coverage_level) (clk, reset_n, start_event, test_expr, end_event); test_expr must not change between start_event and end_event Single-Cycle assert_zero_one_hot #(severity_level, width, property_type, msg, coverage_level) (clk, reset_n, test_expr) test_expr must be one-hot or zero, i.e. at most one bit set high

PARAMETERS USING OVL DESIGN ASSERTIONS INPUT ASSUMPTIONS severity_level +define+OVL_ASSERT_ON Monitors internal signals & Outputs Restricts environment ÒVL_FATAL +define+OVL_MAX_REPORT_ERROR=1 ÒVL_ERROR +define+OVL_INIT_MSG Examples Examples ÒVL_WARNING +define+OVL_INIT_COUNT=<tbench>.ovl_init_count * One hot FSM * One hot inputs ÒVL_INFO * Hit default case items * Range limits e.g. cache sizes property_type

+libext+.v+.vlib

* FIFO / Stack * Stability e.g. cache sizes `OVL_ASSERT

y <OVL_DIR>/std_ovl

* Counters (overflow/increment) * No back-to-back reqs `OVL_ASSUME

+incdir+<OVL_DIR>/std_ovl

* FSM transitions * Handshaking sequences `OVL_IGNORE * X checkers (assert_never_unknown) * Bus protocol msg descriptive string

OVL QUICK REFERENCE (www.eda.org/ovl) Last updated: 28th April 2006

SLIDE 33

Who writes the assertions?

DUV

System Architects Designers / Developers Verification Engineers IP Providers Standards

SLIDE 34

Implementation Assertions

§ Also called “design” assertions. § Specified by the designer/developer.

– Encode designer’s assumptions.

Interface assertions

– Catch different interpretations between different designers.

– Formulate conditions of design misuse or design

faults:

detect buffer over/under flow
signal read & write at the same time when only one

is allowed § Implementation assertions can detect discrepancies between design assumptions and implementation.

SLIDE 35

Specification Assertions

§ Also called “intent” assertions

– Often high-level properties.

§ Specified by architects, verification engineers, IP providers, standards.

– Encode expectations of the design based on

understanding of functional intent.

– Provide a “functional error detection” mechanism. – Supplement error detection performed by self-checking

testbenches.

Instead of using (implementing) a monitor and

checker, in some cases writing a block-level assertion can be much simpler.

SLIDE 36

§ Assertions are able to detect a significant percentage

f design failures:

Assertions should be an integral part of a verification methodology.

Do assertions really work?

[Foster etal.: Assertion-Based Design. 2nd Edition, Kluwer, 2010.]

SLIDE 37

Simulink Diagrams in Control Systems

§ Simulating the control systems § Analysis techniques from control systems theory (e.g., stability) § Serve as requirements/specification § For (automatic) code generation

Code

Control systems design level Implementation level

SLIDE 38

Stability

High-level (abstract) control requirement

Verifying Stability

SLIDE 39

Stability Sub-requirements (parametrized) Matrix P > 0 (Lyapunov function) Matrix P−(A−BK)T P(A−BK) > 0 (Lyapunov function's difference) Equivalence

V(k)-V(k-1) = x(k-1)T [(A−BK)T P(A−BK)-P]x(k-1)

(Lyapunov's equation application) From control systems theory → Lyapunov's second method for stability: Propose Lyapunov function that is

Positive definite
Monotonically decreasing

Verifying Stability

SLIDE 40

Stability Matrix P > 0 (Lyapunov function) Equivalence

V(k)-V(k-1) = x(k-1)T [(A−BK)T P(A−BK)-P]x(k-1)

(Lyapunov's equation application) Add as assertions Capture control systems requirements Retain in code implementation Matrix P−(A−BK)T P(A−BK) > 0 (Lyapunov function's difference)

Verifying Stability

SLIDE 41

Assertion-Based Verification

SLIDE 42

Stability Matrix P > 0 (Lyapunov function) Equivalence

V(k)-V(k-1) = x(k-1)T [(A−BK)T P(A−BK)-P]x(k-1)

(Lyapunov's equation application) Matrix P−(A−BK)T P(A−BK) > 0 (Lyapunov function's difference)

Test in simulation

Combining Verification Techniques

Automatic theorem proving

First order logic theory of the Simulink diagram

Axiom: Bu = B * u ... … Goal: vdiff == vdiff_an

SLIDE 43

Estimators and controllers Stability Functional equivalence Feasibility (constraint satisfaction) Systems in series

Case studies

Hybrid systems

SLIDE 44

Moral

No single technique is adequate to cover a whole design in practice. Combine techniques and learn from areas where verification is more mature.

SLIDE 45

http://github.com/riveras/simulink

D. Araiza Illan, K. Eder, A. Richards.

D. Araiza Illan, K. Eder, A. Richards.

Verification of Control Systems Implemented in Simulink with Assertion Checks and Theorem Proving: A Case Study. European Control Conference (ECC), pp. tbc. Jul 2015. http://arxiv.org/abs/1505.05699

SLIDE 46

DEMO 1:

How to verify control systems implemented in Simulink with assertion checks and theorem proving. A simple case study.

SLIDE 47

Any questions? Kerstin.Eder@bristol.ac.uk Dejanira.AraizaIllan@bristol.ac.uk

Thank you

Special thanks to Dejanira Araiza Illan, David Western, Arthur Richards, Jonathan Lawry, Trevor Martin, Piotr Trojanek, Yoav Hollander, Yaron Kashai, Mike Bartley, Tony Pipe and Chris Melhuish for their hard work, collaboration, inspiration and the many productive discussions we have had.

SLIDE 48