33
CIS 700-3: Selected Topics in Embedded Systems Insup Lee University of Pennsylvania October 11, 2004 Introduction

CIS 700-3: Selected Topics in Embedded Systemslee/04cis700/slides/overview-v1.pdf · Download a toolset and do a demo in class ... Model-carrying code Intrusion detection ... Wireless

Embed Size (px)

Citation preview

CIS 700-3: Selected Topics in Embedded Systems

Insup LeeUniversity of Pennsylvania

October 11, 2004Introduction

Course requirements

Select a topic and then you are expected toDo In-class presentationWrite a survey paperDownload a toolset and do a demo in class

Partial paper listing at www.cis.upen.edu/~lee/04cis700Proceedings of RV’01, RV’02, RV ‘03, RV ’04, WODA 2004.Safeware, Nancy Leveson, Addison Wesley,1995.

List of possible topicsFoundations of run-time verificationProbabilistic run-time verificationMerging partial specificationsTest generation from specifications, hybrid modelsCertification, CMMSafeware, by Nancy LevesonModel-carrying codeIntrusion detection

Signature-based IDS, Model-based IDSAnomaly-based intrusion IDS

Application domains: medical devices, sensor networks, stateless PCModical device architecture and specification; e.g., infusion pumpSecurity in sensor networks

ToolsRun-time verification: JPaXTest generation: ASMLSoftware model checker: BangorRun-time concurrency analyzersEtc.

Embedded SystemsAn embedded system is a system

that interacts with (or reacts to) its environment, and whose correctness is subject to the physical constraints imposed by the environment.

DifficultiesIncreasing complexityDecentralized and networkedResource constrained (e.g. power, size)Safety critical

Development of reliable and robust embedded software

Software Development Process

Requirements

Designspecification

Implementation

Requirements capture and analysisInformal to formalConsistency and completenessAssumptions and interfaces between system componentsApplication- specific properties

Design specifications and analysisFormal modeling notationsAnalysis techniques

simulation, model checking, equivalence checking, testing, etc.Abstractions

ImplementationManual/automatic code generationValidation

TestingModel extraction and verificationRun-time monitoring and checking

Motivation & Objectivesmake each step more rigorous using formal method techniquesnarrow the gaps between phases

RTG: Real-Time Systems GroupGoals:

To develop methods and tools for improving the reliability and quality of real-time embedded systemsTo apply them to real world problems and applications

Projects:Modeling and analysis techniques

requirements capture and analysis: user requirementsdesign specification and analysis: systems and hardware/device platformsTechniques

EMFS (Extended Finite State Machines)CHARON (Hybrid systems: discrete and continuous)

Prototyping using simulator, code generatorTest generation for validation (of real implementation)Runtime monitoring and checkingValidation and CertificationReal-time operating systems, e.g., resource management, scheduling

Application domainsWireless sensor networksMedical devicesStateless PC

Modeling languages and tools

ACSRCHARONEFSM

CHARON languageHierarchical modeling of concurrent embedded systems

Discrete computation, continuous environmentAvionics, automotive, medical device controllers

Architectural hierarchyCommunicating concurrent componentsShared variable communication

Behavioral hierarchyHierarchical hybrid state machinesMode switches, interrupts, exceptions

Formal compositional semantics enables rigorous analysis

Charon toolsetVisual/textual editorsSimulatorReachability analyzerCode generator

CHARON Environment

CHARON Code(High level language)

Java Code

Charon to Java TranslatorCharon to Java Translator

Control Code GeneratorControl Code Generator

Java Libraries

Human InterfaceHuman Interface Analysis

Simulator Code GeneratorSimulator Code Generator

Drivers

Model CheckerModel Checker

Runtime MonitorRuntime Monitor

Formal Requirements

Example: Four Legged Robot

Control objectivev = c

High-level control laws

Low-level control laws

)LL2

LLarccos(

)L2

LLarccos()/arctan(

21

22

21

22

2

221

22

21

22

1

−++=

+

−++−=

yxj

yxyxyxj

x

y

j1

j2

L1

(x, y)

2/stride−≥−=

xvx&

kvy =&2/stride≤

=x

kvx&

kvy −=&

v

L2

CHARON Code GeneratorCommunicating Hybrid

Automata

Discretized CommunicatingHybrid Automata

InstrumentedCommunicating Hybrid

Automata

Code

Continuous time

Discrete synchronous time

Discretetime domain

Heterogeneousdiscrete time domain

Real-time constraints Discrete asynchronous time

CHARON code generator translates CHARON models into C++ code

Each object of CHARON models is translated into a C++ structure

Generated C++ code is compiled by the target compiler along with additional code

Run-time scheduler: invokes active components periodicallyAPI interface routines: associates variables with devices

Correctness of generated code

Bridging the gap between specification and implementation

Model-based code generation and synthesisModel-based testingSoftware model checkingRun-time monitoring and checking (i.e., run-time verification)

Model-based testingSpecification

Model

TestGeneration

TestSuite

Implementation

TestOutcomes

TestExecution

Narrowing the gap between the model and implementationTesting remains the primary validation techniqueModel-based test generation adds rigor to testing:

Provide test suites based on a formally verified modelConventional testing coverage criteria applied to the model

Determines whether an implementation conforms to its specificationTwo main steps

Test generation from specification modelTest execution of implementation

Model-based test generation

Developed a framework for test generation:Model is Extended Finite-State Machines (EFSM)Coverage Criteria

control-flow (e.g., state coverage, transition coverage) data-flow (e.g., all-def, all-use coverage)

Test generation using model checkerCovert test sequences to scripts for test execution

Basis for conformance metrics

SpecificationInput to

model checker

Coveragecriterion

A set of

formulas

Model checker

A set oftests

E[ U ]

Testing-based Validation

Determines whether an implementation conforms to its specification

Hardware and protocol conformance testingWidely-used specifications

Finite state machines and labeled transition systems

Two main stepsTest generation from specifications

What to test, how to generate test

Test execution of implementationsApplies tests to implementations and validates the observed behaviors

Model-based testing

SpecificationModel

Test Output

Test Suite

Implementation

TestGeneration

TestExecution

TestEvaluator

input

output

Run-time verification and checking

Run-time monitoring and checking (MaC) w.r.t. formal specification Ensures the runtime compliance of the current execution of a system with its formal requirement

detect incorrect execution of applicationspredict error and steer computationcollect statistics of actual execution

Complementary methodology to formal verification and program testingPrevention, avoidance, and detection & recovery

The MaC Framework

ProgramProgram

Static Phase

Run-time Phase

low-levelbehavior

high-levelbehaviorProgramProgram Filter

Automatic Instrumentation

Human

Monitoring ScriptsMonitoring ScriptsLow-level

SpecificationHigh-level

Specification

EventRecognizer

EventRecognizer

AutomaticTranslation

Run-time CheckerRun-time Checker

AutomaticTranslation

Input

Informal Requirement

Spec

Case Studies

Experience/case studies in medical devices

CARA infusion pump systemRequirements modeling and analysisDesign specification and analysisHardware in-the-loop simulation

Blood bank policy and DBSSExtracting formal models from FDA guidelinesTest generation from models(evaluation of DBSS for conformance to the FDA guidelines)(testing DBSS)

CARA case studyThe CARA (Computer Assisted Resuscitation Algorithm) infusion pump control system is being developed by WRAIR (Walter Reed Army Institute of Research)Goals:

Study applicability of state-of-the-art formal techniques for development of safety critical embedded systemsSystem modeling from requirementsFormulation and checking of properties on models

General propertiesSpecific safety properties (from requirements)

Caregiver

Infusion Pump

Blood PressureMonitor

Patient

Pump Monitor

Blood PressureMonitor

Algorithm

CaregiverInterface

CARA

Consistencychecker

Model checker

simulator Equality checker

Informal requirements

translator

EFSM

translator translator translator translator

SCR SMV CHARON ACSR

Model checker

translator

DOVE

Etc.

Run realhardware

Comparemodels

Check LTLProperties

Check forCompleteness,

Non-determinism

Check CTLProperties

Interfaces of CARA Simulation

Hardware Setup

CHARONsimulation

Java GUI

ExternalJava Class

JNI

. Cuff Pressure

. AL Pressure

. PW Pressure

. Plug-in

. Continuity

. Occ Ok

. AirOk

. back EMF

. Impedance

Driven voltage(control flow rate /pumping speed)

Status Data/ Message

Manualsignals

Data processing

Hardware in-the-loop Simulation

We connected the CHARON Simulator and GUI to the hardware setup. The hardware consists of four components:

M100 Infusion Pump2 1000mL flasksPressure SensorA/D interface

Blood Bank Case StudyThe FDA Code of Federal Regulations (CFR) requirements are complemented by an explanatory guidance memo. Extract formal models from documents and then analyze for

errors such as incompleteness;inconsistencies between documents; andrequirements traceability and maintenance.

DBSS (Defense Blood Standard System) is the system used by the Army to keep track of their blood supply.

?Errors found include:

• Inconsistency• Incompleteness

Our approachCFR Memo CFR and Memo documents

are translated into formal models. Merge multiple models into a single model to

Verify using formal methods techniques Generate test suite

Working on semi-automatic way to extract models using NLP techniquesArmy’s DBSS

NLP NLP

CFRModel

MemoModel

Merging

SystemModel

Policy Modeling and VerificationManual

Translationand Merging

SystemSpecification

NLDocuments

ParagraphsParagraphsNLFSMsBuildNLFSM

Test ScriptGeneration

Tool

PropertiesCertification

TestScripts

ProgramCode

TestOutcomes

CertificationCriteria

Certifier

Tester

Programmer

1. Write NL Requirements2. Extract formal System Specification

(EFSMs)3. Programmer implements system4. Create Test Scripts5. Tester runs scripts on implementation6. Certifier uses test results and properties to

decide if implementation passes

Yes / NoOutcome

The HASTEN ProjectHigh Assurance Systems Tools and ENvironments(HASTEN)Develop techniques and tools for “end-to-end” software engineering of embedded systems

Requirements captureSpecification, analysis, simulationImplementation generation and validation: code generation, testingDeployed system monitoring, checking, and steering

Integrated use of tools and artifactsVertical integration: multiple uses of modelsHorizontal integration: multiplicity of techniques

Case Studies and Tech Transfers

Opportunities and ChallengesModeling challenges

Semi-automatic extraction of formal models from informal docsComposition of partial, heterogeneous models

Open-source requirements and modelsMultiple use and sharing of modeling artifactsAssess to domain experts & Model validationCertification based on modelsBenchmarks for tool evaluation

Support for system integrationApplying model-based techniques to legacy codeExtracting behavioral interfacesCompositional real-time scheduling framework

Certification challengesMetrics based on formal method foundations

The End.