Formal Verification of an Automotive Scenario inService-Oriented Computing
Maurice ter Beek1
Stefania Gnesi1 Nora Koch2 Franco Mazzanti1
1ISTI-CNRPisa, Italy
2Cirquent GmbH and LMUMünchen, Germany
Experience Track on Automotive SystemsICSE’08, Leipzig, Germany
Thursday 15 May 2008
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 1 / 26
Outline
1 Background
2 Automotive Scenario
3 Formal Verification
4 Lessons Learned
5 Future Work
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 2 / 26
Current State of Automotive Industry
80% of innovation cost of car due to software systems25% of total costs of finished car due to software costs> 70 electronic control units (ECUs) requiring specific software
⇒ Great potential for software technologies
A. Saad (Car-IT, BMW) Javaspektrum 2/2003M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 3 / 26
Trends in Automotive Industry
Cars have an increasing number of embedded software componentsto meet emissions and fuel-economy standardsto advance diagnosticsto improve safetyto reduce coststo add comfort and infotainment features
Requires networking of embedded software components as well asnetworking of car and environment
⇒ Increased system complexity and increased dependencies
“Mitsubishi Electric Corporation, IBM and ILS Technology LLC[. . . ] are delivering a service oriented architecture (SOA) so-lution that is specifically designed for the automotive manufac-turing industry.” (Press release, 31 Jan. 2008)
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 4 / 26
Trends in Automotive Industry
Cars have an increasing number of embedded software componentsto meet emissions and fuel-economy standardsto advance diagnosticsto improve safetyto reduce coststo add comfort and infotainment features
Requires networking of embedded software components as well asnetworking of car and environment
⇒ Increased system complexity and increased dependencies
“Mitsubishi Electric Corporation, IBM and ILS Technology LLC[. . . ] are delivering a service oriented architecture (SOA) so-lution that is specifically designed for the automotive manufac-turing industry.” (Press release, 31 Jan. 2008)
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 4 / 26
Trends in Automotive Industry
Cars have an increasing number of embedded software componentsto meet emissions and fuel-economy standardsto advance diagnosticsto improve safetyto reduce coststo add comfort and infotainment features
Requires networking of embedded software components as well asnetworking of car and environment
⇒ Increased system complexity and increased dependencies
“Mitsubishi Electric Corporation, IBM and ILS Technology LLC[. . . ] are delivering a service oriented architecture (SOA) so-lution that is specifically designed for the automotive manufac-turing industry.” (Press release, 31 Jan. 2008)
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 4 / 26
Formal verification of SOC applications
Service-Oriented ComputingSOC is an emerging paradigm for developing loosely coupled,interoperable, evolvable systems and applications, exploiting thepervasiveness of the Internet and its related technologies
Goal of our researchDevelop formal reasoning mechanisms and analytical tools forchecking that the services resulting from a composition meet desirablecorrectness properties and do not manifest unexpected behaviours
SENSORIA: http://www.sensoria-ist.eu/Work performed in context of EU project SENSORIA: Develop acomprehensive and pragmatic (but theoretically well-founded)approach to software engineering for service-oriented systems
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 5 / 26
Formal verification of SOC applications
Service-Oriented ComputingSOC is an emerging paradigm for developing loosely coupled,interoperable, evolvable systems and applications, exploiting thepervasiveness of the Internet and its related technologies
Goal of our researchDevelop formal reasoning mechanisms and analytical tools forchecking that the services resulting from a composition meet desirablecorrectness properties and do not manifest unexpected behaviours
SENSORIA: http://www.sensoria-ist.eu/Work performed in context of EU project SENSORIA: Develop acomprehensive and pragmatic (but theoretically well-founded)approach to software engineering for service-oriented systems
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 5 / 26
On Road Assistance Scenario
On the road, a vehicle’s diagnostic system reports a low oil levelTriggers in-vehicle diagnostic system: car no longer driveable,send diagnostic data and car’s GPS coordinates to repair serverGiven driver’s preferences, service discovery system identifies andselects appropriate services (garage/tow truck/rental car) in areaWhen driver makes appointment with garage, results of in-vehiclediagnosis are automatically sent along, allowing garage to identifythe spare parts needed to repair carSimilarly, when driver orders tow truck and rental car, the car’sGPS coordinates are sent alongObviously, driver is required to deposit a security payment beforebeing able to order any serviceEach service can be denied or cancelled, causing compensation
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 6 / 26
UML4SOA
Extension with stereotypes and constraints specified in OCLN. Koch, P. Mayer, R. Heckel, L. Gönczy and C. Montangero, UML forService-Oriented Systems. SENSORIA Deliverable 1.4a, Sept. 2007
http://www.uml4soa.eu/
SOA structure diagrams:�service�/�service interface�/�service description�
Stereotypes for service interactions, long-running transactions, andtheir compensation and exception handling:
�scope� is a structured activity that groups actions�compensation edge�/�exception edge� to link scopes and handlers�send�/�received�/�send and receive� for send and receive actions�compensate�/�compensate all� to trigger the execution of thecompensation defined for a scope or activity; compensation iscalled on all subscopes in reverse order of completion
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 7 / 26
UML4SOA
Extension with stereotypes and constraints specified in OCLN. Koch, P. Mayer, R. Heckel, L. Gönczy and C. Montangero, UML forService-Oriented Systems. SENSORIA Deliverable 1.4a, Sept. 2007
http://www.uml4soa.eu/
SOA structure diagrams:�service�/�service interface�/�service description�
Stereotypes for service interactions, long-running transactions, andtheir compensation and exception handling:
�scope� is a structured activity that groups actions�compensation edge�/�exception edge� to link scopes and handlers�send�/�received�/�send and receive� for send and receive actions�compensate�/�compensate all� to trigger the execution of thecompensation defined for a scope or activity; compensation iscalled on all subscopes in reverse order of completion
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 7 / 26
Components of UML Specification
UML 2.0 specification using UML4SOAN. Koch and D. Berndl, Requirements Modelling and Analysis ofSelected Scenarios of the Automative Case Study. SENSORIADeliverable 8.2a, Sept. 2007
Engine: causes low oil level alertDiscovery engine: discovers services neededReasoner: selects best servicesOrchestrator: composes services to achieve goalDriver: calls garage, tow truck, rental car and bankGPS: sends vehicle’s current coordinates to servicesGarage: receives diagnostic data about vehicleTow truck: receives GPS coordinates of vehicleRental car: receives GPS coordinates of driverBank: receives deposit from driver
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 8 / 26
Components of UML Specification
UML 2.0 specification using UML4SOAN. Koch and D. Berndl, Requirements Modelling and Analysis ofSelected Scenarios of the Automative Case Study. SENSORIADeliverable 8.2a, Sept. 2007
Engine: causes low oil level alertDiscovery engine: discovers services neededReasoner: selects best servicesOrchestrator: composes services to achieve goalDriver: calls garage, tow truck, rental car and bankGPS: sends vehicle’s current coordinates to servicesGarage: receives diagnostic data about vehicleTow truck: receives GPS coordinates of vehicleRental car: receives GPS coordinates of driverBank: receives deposit from driver
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 8 / 26
Activity Diagram: Orchestration of Services
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 9 / 26
Activity Diagram: Orchestration of Services (cont’d)
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 10 / 26
Operational Model: Communicating State Machines
Subcomponent BankCommunication
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 11 / 26
Modelling Assumptions
We do not define a separate state machine for each component,but rather structure some of them as subcomponents of othersWe abstract altogether from a remote discovery state machine(to search for services in a remote repository)LocalDiscovery returns at most one choice of servicesCompensations are explicitly modelled as requests to canceloperations (viz. bankrevoke and garagerevoke)All communications between Car’s subcomponents, and thosebetween these subcomponents and Bank and RoadAssistance(i.e. all service invocations), modelled as request/response pairs
(whereas this is necessary for the former (synchronous operationcalls would deadlock), the latter might equally well be modelled assynchronous operation calls)
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 12 / 26
Structure Diagram of State Machines
⇒ Validation by hand is not feasible: 535 states and 814 transitions
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 13 / 26
Model Checking
Model checkingAutomatic analysis of correctness properties of system designs;such verifications are exhaustive, i.e. all possible input combinationsand states are taken into account, and a counterexample is usuallygenerated in case a certain property does not hold
Correctness properties: (un)desired system behaviourQualitative: functional properties (considered in this paper )Quantitative: performance/dependability properties (future)
Advantage: detect design errors before implementationDesign errors — which constitute up to 40% of software errors and areamong the most expensive ones to resolve if discovered afterimplementation [LRRA98] — can be detected in the design phase,leading to considerable reductions in cost and to improved quality
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 14 / 26
Model Checking
Model checkingAutomatic analysis of correctness properties of system designs;such verifications are exhaustive, i.e. all possible input combinationsand states are taken into account, and a counterexample is usuallygenerated in case a certain property does not hold
Correctness properties: (un)desired system behaviourQualitative: functional properties (considered in this paper )Quantitative: performance/dependability properties (future)
Advantage: detect design errors before implementationDesign errors — which constitute up to 40% of software errors and areamong the most expensive ones to resolve if discovered afterimplementation [LRRA98] — can be detected in the design phase,leading to considerable reductions in cost and to improved quality
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 14 / 26
Model Checking
Model checkingAutomatic analysis of correctness properties of system designs;such verifications are exhaustive, i.e. all possible input combinationsand states are taken into account, and a counterexample is usuallygenerated in case a certain property does not hold
Correctness properties: (un)desired system behaviourQualitative: functional properties (considered in this paper )Quantitative: performance/dependability properties (future)
Advantage: detect design errors before implementationDesign errors — which constitute up to 40% of software errors and areamong the most expensive ones to resolve if discovered afterimplementation [LRRA98] — can be detected in the design phase,leading to considerable reductions in cost and to improved quality
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 14 / 26
The Need for Action- and State-based Logics
Model checking primarily evolved over Kripke structuresInformation associated to states (e.g. SMV, NuSMV, etc.)This approach is particularly amenable to modelling hardware
Theory of concurrency evolved over Labelled Transition SystemsInformation associated to transitions (CCS, LOTOS, π-calculus, etc.)Many aspects of software (in particular the most interesting ones forreactive, concurrent and distributed software) are events, i.e. actions
The emerging trend in industry is to use UML (state diagrams)
Ease of expressiveness w.r.t. pure action- or state-based logicsTheir use often leads to a reduced state space, small memoryneeds and less time spent for verification
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 15 / 26
The Need for Action- and State-based Logics
Model checking primarily evolved over Kripke structuresInformation associated to states (e.g. SMV, NuSMV, etc.)This approach is particularly amenable to modelling hardware
Theory of concurrency evolved over Labelled Transition SystemsInformation associated to transitions (CCS, LOTOS, π-calculus, etc.)Many aspects of software (in particular the most interesting ones forreactive, concurrent and distributed software) are events, i.e. actions
The emerging trend in industry is to use UML (state diagrams)
Ease of expressiveness w.r.t. pure action- or state-based logicsTheir use often leads to a reduced state space, small memoryneeds and less time spent for verification
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 15 / 26
The Need for Action- and State-based Logics
Model checking primarily evolved over Kripke structuresInformation associated to states (e.g. SMV, NuSMV, etc.)This approach is particularly amenable to modelling hardware
Theory of concurrency evolved over Labelled Transition SystemsInformation associated to transitions (CCS, LOTOS, π-calculus, etc.)Many aspects of software (in particular the most interesting ones forreactive, concurrent and distributed software) are events, i.e. actions
To use the full potential of specification languages (like UML) thatallow both action and state changes to be modelled, various action-and state-based logics have been developed
Ease of expressiveness w.r.t. pure action- or state-based logicsTheir use often leads to a reduced state space, small memoryneeds and less time spent for verification
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 15 / 26
The Need for Action- and State-based Logics
Model checking primarily evolved over Kripke structuresInformation associated to states (e.g. SMV, NuSMV, etc.)This approach is particularly amenable to modelling hardware
Theory of concurrency evolved over Labelled Transition SystemsInformation associated to transitions (CCS, LOTOS, π-calculus, etc.)Many aspects of software (in particular the most interesting ones forreactive, concurrent and distributed software) are events, i.e. actions
To use the full potential of specification languages (like UML) thatallow both action and state changes to be modelled, various action-and state-based logics have been developed
Ease of expressiveness w.r.t. pure action- or state-based logicsTheir use often leads to a reduced state space, small memoryneeds and less time spent for verification
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 15 / 26
Temporal Logic UCTL
UCTL: Action- and State-based Branching-time Temporal LogicM.H. ter Beek, A. Fantechi, S. Gnesi and F. Mazzanti, Anaction/state-based model-checking approach for the analysis ofcommunication protocols for Service-Oriented Applications. InProceedings 12th International Workshop on Formal Methods forIndustrial Critical Systems (FMICS’07), LNCS 4916, 2008, 133–148.
UCTL defined as extension of action-based CTL (ACTL [DNV90])UCTL includes both CTL and ACTLAll possible system evolutions are formally represented as aDoubly-labelled Transition System (L2TS) [DNV95]
states represent the various system configurationsedges represent the possible evolutions of a system configuration
The service-oriented logic SOCL is a recent specialization of UCTLmeant to capture peculiar aspects of services [FGLMPT08]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 16 / 26
Temporal Logic UCTL
UCTL: Action- and State-based Branching-time Temporal LogicM.H. ter Beek, A. Fantechi, S. Gnesi and F. Mazzanti, Anaction/state-based model-checking approach for the analysis ofcommunication protocols for Service-Oriented Applications. InProceedings 12th International Workshop on Formal Methods forIndustrial Critical Systems (FMICS’07), LNCS 4916, 2008, 133–148.
UCTL defined as extension of action-based CTL (ACTL [DNV90])UCTL includes both CTL and ACTLAll possible system evolutions are formally represented as aDoubly-labelled Transition System (L2TS) [DNV95]
states represent the various system configurationsedges represent the possible evolutions of a system configuration
The service-oriented logic SOCL is a recent specialization of UCTLmeant to capture peculiar aspects of services [FGLMPT08]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 16 / 26
Temporal Logic UCTL
UCTL: Action- and State-based Branching-time Temporal LogicM.H. ter Beek, A. Fantechi, S. Gnesi and F. Mazzanti, Anaction/state-based model-checking approach for the analysis ofcommunication protocols for Service-Oriented Applications. InProceedings 12th International Workshop on Formal Methods forIndustrial Critical Systems (FMICS’07), LNCS 4916, 2008, 133–148.
UCTL defined as extension of action-based CTL (ACTL [DNV90])UCTL includes both CTL and ACTLAll possible system evolutions are formally represented as aDoubly-labelled Transition System (L2TS) [DNV95]
states represent the various system configurationsedges represent the possible evolutions of a system configuration
The service-oriented logic SOCL is a recent specialization of UCTLmeant to capture peculiar aspects of services [FGLMPT08]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 16 / 26
UCTL: Syntax
Action formulae syntaxLet Act be a set of observable events. Then the language of eventformulae on Act ∪ {τ} is defined as follows:
χ ::= true | e | τ | ¬χ | χ ∧ χ
UCTL syntax
(state formulae) φ ::= true | π | ¬φ | φ ∧ φ′ | EΨ | AΨ
(path formulae) Ψ ::= Xγφ | φ χU φ′ | φ χUγ φ′ | φ χW φ′ | φ χWγ φ
′
Some derived modalities< γ > φ stands for EXγ φ [γ]φ stands for ¬ < γ > ¬φEFφ stands for E(true true Uφ) AG φ stands for ¬EF ¬φ
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 17 / 26
UCTL: Syntax
Action formulae syntaxLet Act be a set of observable events. Then the language of eventformulae on Act ∪ {τ} is defined as follows:
χ ::= true | e | τ | ¬χ | χ ∧ χ
UCTL syntax
(state formulae) φ ::= true | π | ¬φ | φ ∧ φ′ | EΨ | AΨ
(path formulae) Ψ ::= Xγφ | φ χU φ′ | φ χUγ φ′ | φ χW φ′ | φ χWγ φ
′
Some derived modalities< γ > φ stands for EXγ φ [γ]φ stands for ¬ < γ > ¬φEFφ stands for E(true true Uφ) AG φ stands for ¬EF ¬φ
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 17 / 26
UCTL: Syntax
Action formulae syntaxLet Act be a set of observable events. Then the language of eventformulae on Act ∪ {τ} is defined as follows:
χ ::= true | e | τ | ¬χ | χ ∧ χ
UCTL syntax
(state formulae) φ ::= true | π | ¬φ | φ ∧ φ′ | EΨ | AΨ
(path formulae) Ψ ::= Xγφ | φ χU φ′ | φ χUγ φ′ | φ χW φ′ | φ χWγ φ
′
Some derived modalities< γ > φ stands for EXγ φ [γ]φ stands for ¬ < γ > ¬φEFφ stands for E(true true Uφ) AG φ stands for ¬EF ¬φ
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 17 / 26
Model Checkers for UCTL/SOCL
We have developed on-the-fly model checkers to verify UCTL/SOCLformulae (specifying both action- and state-based properties) over aset of communicating UML state machines
Current UMC/CMC prototypes can be experimented via a web interface
http://fmt.isti.cnr.it/{u/c}mc
We have used UMC v3.4 on an ordinary PC to verify a number ofbehavioural properties expressed in UCTL over our implementation ofthe on road assistance scenario
The verifications show that the requirements model of the on roadassistance scenario has been well designed in [KB07]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 18 / 26
Model Checkers for UCTL/SOCL
We have developed on-the-fly model checkers to verify UCTL/SOCLformulae (specifying both action- and state-based properties) over aset of communicating UML state machines
Current UMC/CMC prototypes can be experimented via a web interface
http://fmt.isti.cnr.it/{u/c}mc
We have used UMC v3.4 on an ordinary PC to verify a number ofbehavioural properties expressed in UCTL over our implementation ofthe on road assistance scenario
The verifications show that the requirements model of the on roadassistance scenario has been well designed in [KB07]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 18 / 26
Service Responsiveness
A service is responsive if it guarantees a responseto each received request
If Car requests Bank to charge a credit card, thenBank will reply by notifying either a successful or afailed attempt to charge the credit card
UCTL property F1AG [ requestCardCharge ]
A [ true true U chargeResponseOK∨chargeResponseFail true ]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 19 / 26
Service Responsiveness
A service is responsive if it guarantees a responseto each received request
If Car requests Bank to charge a credit card, thenBank will reply by notifying either a successful or afailed attempt to charge the credit card
UCTL property F1AG [ requestCardCharge ]
A [ true true U chargeResponseOK∨chargeResponseFail true ]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 19 / 26
Service Responsiveness
A service is responsive if it guarantees a responseto each received request
If Car requests Bank to charge a credit card, thenBank will reply by notifying either a successful or afailed attempt to charge the credit card
UCTL property F1AG [ requestCardCharge ]
A [ true true U chargeResponseOK∨chargeResponseFail true ]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 19 / 26
Service Reliability
A service is reliable if it guarantees a successfulresponse whenever it accepts a request (for thisservice)
Reservation requests from Car to Garage are al-ways followed by a notification of success
UCTL property F3AG [ requestGarage ]
A [ true true UgarageResponseOK true ]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 20 / 26
Service Reliability
A service is reliable if it guarantees a successfulresponse whenever it accepts a request (for thisservice)
Reservation requests from Car to Garage are al-ways followed by a notification of success
UCTL property F3AG [ requestGarage ]
A [ true true UgarageResponseOK true ]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 20 / 26
Service Reliability
A service is reliable if it guarantees a successfulresponse whenever it accepts a request (for thisservice)
Reservation requests from Car to Garage are al-ways followed by a notification of success
UCTL property F3AG [ requestGarage ]
A [ true true UgarageResponseOK true ]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 20 / 26
Uniqueness of Response
A service guarantees uniqueness of response if itguarantees a single successful response wheneverit accepts a request (for this service)
After a reservation request from Car to Garage, itcannot happen that the Car receives more than onenotification
UCTL property F4AG [ requestGarage ] AF <garageResponse>
¬EF <garageResponse> true
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 21 / 26
Uniqueness of Response
A service guarantees uniqueness of response if itguarantees a single successful response wheneverit accepts a request (for this service)
After a reservation request from Car to Garage, itcannot happen that the Car receives more than onenotification
UCTL property F4AG [ requestGarage ] AF <garageResponse>
¬EF <garageResponse> true
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 21 / 26
Uniqueness of Response
A service guarantees uniqueness of response if itguarantees a single successful response wheneverit accepts a request (for this service)
After a reservation request from Car to Garage, itcannot happen that the Car receives more than onenotification
UCTL property F4AG [ requestGarage ] AF <garageResponse>
¬EF <garageResponse> true
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 21 / 26
Validation with UMC
formula property validityF1 service responsiveness trueF2 service coordination trueF3 service reliability falseF4 uniqueness of response trueF5 functional system behaviour true
Table: Validation results.
⇒ Not surprising that F3 is false: Garage might be temporarilyunable to provide the requested service and thus send theunsuccessful response garageResponseFail
(note that Garage is responsive: F1-like formula does hold)
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 22 / 26
Lessons Learned
On road assistance scenario was outcome of discussions withautomotive experts on possible new services for drivers to beprovided by the in-vehicle computersValidation shows requirements model has been well designedCase study moreover shows usefulness and feasibility of a formalapproach to specify and rigorously analyze a system design, alsoin industrial contextsRoom for improvement of our model checker: regarding UMLsupport of the tool, regarding further optimizations of on-the-flymodel-checking algorithm and regarding overall usability anduser-interface issues
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 23 / 26
Future Work
Relax modelling assumptions made w.r.t. requirements models
Verify more complex scenarios (drivers competing for tow trucks)
Quantitative analysis of on road assistance scenario
Improve the UCTL/SOCL model checker
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 24 / 26
Future Work
Relax modelling assumptions made w.r.t. requirements models
Verify more complex scenarios (drivers competing for tow trucks)
Quantitative analysis of on road assistance scenario
Improve the UCTL/SOCL model checker
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 24 / 26
Future Work
Relax modelling assumptions made w.r.t. requirements models
Verify more complex scenarios (drivers competing for tow trucks)
Quantitative analysis of on road assistance scenario
Improve the UCTL/SOCL model checker
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 24 / 26
Service Coordination
A service is coordinated if its confirmation is alwayspreceded by a request (for this service)
Car cannot receive a notification of the fact that thecredit card has been charged, if it did not previouslyrequest Bank to do so
UCTL property F2¬ E [ true ¬requestCardCharge U chargeResponseOK true ]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 25 / 26
Service Coordination
A service is coordinated if its confirmation is alwayspreceded by a request (for this service)
Car cannot receive a notification of the fact that thecredit card has been charged, if it did not previouslyrequest Bank to do so
UCTL property F2¬ E [ true ¬requestCardCharge U chargeResponseOK true ]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 25 / 26
Service Coordination
A service is coordinated if its confirmation is alwayspreceded by a request (for this service)
Car cannot receive a notification of the fact that thecredit card has been charged, if it did not previouslyrequest Bank to do so
UCTL property F2¬ E [ true ¬requestCardCharge U chargeResponseOK true ]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 25 / 26
Functional System Behaviour
For instance: success of a service request is alwaysfollowed by either its cancellation or by the successof another service request
If Bank notifies Car of successfully charging thecredit card, then in the future either this operationwill be revoked or Car will receive a notification ofthe fact that Garage has been reserved
UCTL property F5AG [ chargeResponseOK ]
A [ true true UgarageResponseOK∨bankrevokeOK true ]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 26 / 26
Functional System Behaviour
For instance: success of a service request is alwaysfollowed by either its cancellation or by the successof another service request
If Bank notifies Car of successfully charging thecredit card, then in the future either this operationwill be revoked or Car will receive a notification ofthe fact that Garage has been reserved
UCTL property F5AG [ chargeResponseOK ]
A [ true true UgarageResponseOK∨bankrevokeOK true ]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 26 / 26
Functional System Behaviour
For instance: success of a service request is alwaysfollowed by either its cancellation or by the successof another service request
If Bank notifies Car of successfully charging thecredit card, then in the future either this operationwill be revoked or Car will receive a notification ofthe fact that Garage has been reserved
UCTL property F5AG [ chargeResponseOK ]
A [ true true UgarageResponseOK∨bankrevokeOK true ]
M.H. ter Beek (ISTI-CNR) Verification of Automotive Scenario in SOC ICSE’08, 15 May 2008 26 / 26
