10 th January 2007 www.QinetiQ.com QinetiQ in confidence © Copyright QinetiQ 1.

Slides:



Advertisements
Similar presentations
© Copyright QinetiQ limited 2006 Objectives of Coding Standards & MISRA C++ Clive Pygott, Systems Assurance Group, QinetiQ Chris Tapp, Keylevel Consultants.
Advertisements

Software change management
Configuration management
Database Planning, Design, and Administration
Verification and Validation
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
What is Software Design?. Systems Development Life- Cycle Planning Analysis Design Implementation Design.
Chapter 4 Quality Assurance in Context
Chapter 2 – Software Processes
Presented by: Thabet Kacem Spring Outline Contributions Introduction Proposed Approach Related Work Reconception of ADLs XTEAM Tool Chain Discussion.
Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor Formal Methods in Software Engineering1.
1 Certification Chapter 14, Storey. 2 Topics  What is certification?  Various forms of certification  The process of system certification (the planning.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
Software Requirements
Establishing the overall structure of a software system
The Systems Assurance Group Dr Jaspal Sagoo Systems Assurance Group QinetiQ Trusted Information Management Malvern Technology Centre.
Software Engineering Tools and Methods Presented by: Mohammad Enamur Rashid( ) Mohammad Rashim Uddin( ) Masud Ur Rahman( )
Verification and Validation
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Chapter 3 Software Processes.
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR.
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
Software Testing Verification and validation planning Software inspections Software Inspection vs. Testing Automated static analysis Cleanroom software.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
Database System Development Lifecycle © Pearson Education Limited 1995, 2005.
Overview of the Database Development Process
Verification and Validation Yonsei University 2 nd Semester, 2014 Sanghyun Park.
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Verification and Validation.
Chapter 2 The process Process, Methods, and Tools
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Architectural Design portions ©Ian Sommerville 1995 Establishing the overall structure of a software system.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 1 Software Processes l Coherent sets of activities for specifying, designing,
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Configuration Management (CM)
© Andrew IrelandDependable Systems Group ITI Techmedia and Technology Transfer Andrew Ireland Dependable Systems Group School of Mathematical & Computer.
Architectural Design lecture 10. Topics covered Architectural design decisions System organisation Control styles Reference architectures.
Verification and Validation in the Context of Domain-Specific Modelling Janne Merilinna.
Architectural Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Software Verification, Validation and Testing.
1 Introduction to Software Engineering Lecture 1.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Chapter 19 Verification and Validation.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
QinetiQ in confidence © Copyright QinetiQ November 2008 Challenges Colin O’Halloran Aerospace Consulting Practice.
Open Incremental Model Checking (OIMC) and the Role of Contracts Model-Based Programming and Verification.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
ARTEMIS JU Grant Agreement number WP4 Instantiation WP4 Status 25 September, 2013.
Process Asad Ur Rehman Chief Technology Officer Feditec Enterprise.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
HNDIT23082 Lecture 09:Software Testing. Validations and Verification Validation and verification ( V & V ) is the name given to the checking and analysis.
CS223: Software Engineering
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Slide 1 Chapter 8 Architectural Design. Slide 2 Topics covered l System structuring l Control models l Modular decomposition l Domain-specific architectures.
Enterprise Architectures Course Code : CPIS-352 King Abdul Aziz University, Jeddah Saudi Arabia.
Chapter 9 Database Planning, Design, and Administration Transparencies © Pearson Education Limited 1995, 2005.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
CS 389 – Software Engineering
Chapter 18 Maintaining Information Systems
Software Processes (a)
Chapter 2 – Software Processes
QGen and TQL-1 Qualification
QGen and TQL Qualification
CSC-682 Advanced Computer Security
Presentation transcript:

10 th January QinetiQ in confidence © Copyright QinetiQ 1

27 th November 2007 EVOCS work relevant to MOSAIC Colin O’Halloran A presentation to: University of York

10 th January QinetiQ in confidence © Copyright QinetiQ 3 Contents slide 01 WP4.1.1 Background 02 WP Extension of CLawZ Simulink Subset 03 WP Development of Veriflow Subset 04 WP4.1.2 Background 05 WP4.1.2 Formalised C Subset and Analysis Tools 06 WP Robustness Analysis 07 WP Background 08 WP Extension of the QinetiQ Dependability Library to automotive applications

10 th January QinetiQ in confidence © Copyright QinetiQ 4 WP4.1 Automated and Formal Model Based Design WP –Background Previous work has focussed on safety critical code for flight control laws and the Ada programming language. The tools therefore need to be adapted to cope with the needs of the automotive sector which means the adoption of the C programming language as well as extending the subsets of the modelling tools as they currently stand. The focus of this work is on individual, high dependability, complex systems which will then form part of a System of Systems.

10 th January QinetiQ in confidence © Copyright QinetiQ 5 WP4.1 Automated and Formal Model Based Design WP Extension of CLawZ Simulink Subset –The CLawZ Simulink subset has been supplied to partners for evaluation –An sample of Simulink models have been assessed by QinetiQ Continuous blocks, such as versions“Clock”, “Integrator” and “Memory”, must be replaced by discrete versions for autocoding and verification. Certain blocks are purely for modelling purposes and are irrelevant to autocoding an implementation, e.g. “From Workspace”, “To Workspace” and the CAN blockset. MATLAB interfaces are problematic because they allow implementation programs to be smuggled in rather than models for autocode. S-Functions explicitly allow implementations to be smuggled in. A recently developed Z producer supports extensions to the Simulink subset, the intention is to support data type conversions, “From” and “Goto” blocks, but undisciplined use of “Goto” and “From” leads to maintenance cost issues.

10 th January QinetiQ in confidence © Copyright QinetiQ 6 WP4.1 Automated and Formal Model Based Design WP Development of Veriflow Subset –Extended tool to automatically generate Z specification from a Stateflow model in order to accommodate large models and automotive style –Some validation with “Improved Hood Controller” model supplied by Jaguar-Land Rover. –Revealed an inefficiency in the tool that is being investigated –Tool also generated Ada code to trial approach verification approach using Aerospace toolset –Verification from an aerospace domain model to Ada code conducted successfully with measurements for time taken. –First order measurements indicate that time and cost is equivalent to that taken for the development of safety critical code.

10 th January QinetiQ in confidence © Copyright QinetiQ 7 WP4.1 Automated and Formal Model Based Design WP –Background In order to undertake analysis of the code, a relevant subset of the C programming language will need to be formalised in Z. This subset will be based upon the MISRA guidelines, but will be focussed on semantic as well as syntactic correctness. The breadth of the C subset will provide constraints on the eventual uses, but will ensure that the code is amenable to analysis through the use of automated proof.

10 th January QinetiQ in confidence © Copyright QinetiQ 8 WP4.1 Automated and Formal Model Based Design WP Formalised C Subset and Analysis Tools –MISRA compliant subset language called C ♭ has been defined –A formal semantics in Z for C ♭ statements (this includes assignment) has been defined except for function calls (deferred but straightforward) A formal semantics in Z for most C ♭ expressions has been defined, some binary expressions and “sizeof” expressions to be done (function calls deferred but straightforward) –A prototype verification tool based on the formal semantics has been developed and forms part of a validation of the formal semantics.

10 th January QinetiQ in confidence © Copyright QinetiQ 9 WP4.1 Automated and Formal Model Based Design WP –Background Although code can be correct with respect to the design, it is often not apparent at the design stage that the design decisions have implications for the code. These decisions relate to the context of use of the system. In particular, there are 2 main areas of concern: the environment and the processor. This WP will carry out robustness analysis in the context of system and platform though the use of automatic static analysis techniques.

10 th January QinetiQ in confidence © Copyright QinetiQ 10 Malporte 2.0 status WP Robustness Analysis –Objectives have remained unchanged Evolution Soundness Speed Accuracy –Introduction of generics into C# to re-implement and simplify Malporte 2.0 architecture.

10 th January QinetiQ in confidence © Copyright QinetiQ 11 Malporte 2.0 status

10 th January QinetiQ in confidence © Copyright QinetiQ 12 Malporte 2.0 status Malporte 2.0 architecture reflects Architecture Neutral Distribution Format (ANDF) Open Software Foundation standard and contains a formal model of memory and access to memory. –This underpins soundness and supports evolution. –Allows incremental development Architecture separates out concerns of symbolic execution and mathematical predicates that describe values in memory and the conditions of access to memory. There are hundreds of ANDF constructs that are represented by C# methods on classes. Only a fraction of the constructs are used for any specific program and some constructs are seldom used (one construct we have never seen used in practice).

10 th January QinetiQ in confidence © Copyright QinetiQ 13 Malporte 2.0 status The ongoing work is the implementation of the methods for these constructs. There are certain key constructs that correspond to loops, procedure calls and structures in memory –These take a few weeks to implement and test Most of the rest take hours or minutes to implement, a small minority will take a few days. Progress has been good and QinetiQ are currently analysing an avionics ILS while implementing the methods corresponding to the ANDF constructors used in the C code. Validation against Malporte 1.2 results for an ILS occurred at end of October. By December we aim to validate Malporte 2.0 against signal conditioning code in an avionics DECMU.

10 th January QinetiQ in confidence © Copyright QinetiQ 14 Malporte 2.0 next steps Incorporate WMG evaluation into Malporte 2.0 incremental development Determine ANDF constructors required for next phase of evaluation Compare with ANDF constructors covered for aerospace domain Determine what extra constructors require implementation, if any, and focus on these for WMG evaluation. In parallel we will be working on simplifying predicate conditions that characterise when software is vulnerable to unpredictable behaviour. –Will support human validation and the next phase of WMG evaluation

10 th January QinetiQ in confidence © Copyright QinetiQ 15 WP4.2 Dependable Systems of Systems WP –Background Following the selection of a critical part of an automotive SoS architecture, we will develop the Dependability Library (DL) of building blocks to formally represent the specifications of the individual systems’ interfaces. This will include the communications medium and will involve the use of various formalisms in combination, as the properties of any one particular system cannot be represented by one alone. A key component of this extension is the development of automated specification generation from which it should be possible to provide tailor-able building blocks.

10 th January QinetiQ in confidence © Copyright QinetiQ 16 WP4.2 Dependable Systems of Systems WP Extension of the QinetiQ Dependability Library to automotive applications –Development of A/C reasoning for automotive domain Vertical A/C ideas –Workshop on benefits of A/C reasoning for SoS and identification of case studies from JLR A/C reasoning supports separate description and validation of individual systems Enables compositional reasoning (systems by contracts) Suitable for legacy or Off The Shelf systems unlike usual approaches –Information and models on Immobilisation and Infotainment SoSs provided by JLR –Model of immobiliser with library components developed and properties of interest identified with checks –Compilation problem with FDR holding this up at the moment –Scalability o f analysis is the next step