Software architecture in ASPICE and Even-André Karlsson

Size: px
Start display at page:

Download "Software architecture in ASPICE and Even-André Karlsson"

Transcription

1 Software architecture in ASPICE and Even-André Karlsson

2 Agenda Overall comparison (3 min) Why is the architecture documentation difficult? (2 min) ASPICE requirements (8 min) requirements (12 min) Comparison and questions (5 min) Discussion tomorrow in workshop 2

3 Relation between ASPICE and ASPICE is a maturity capability standard with a large coverage - No generic practices in 26262, but some level 2 & 3 requirements on tailoring and selection is a safety standard with increasing requirements depending on ASIL level 26262: Little focus on organizational processes, metrics or improvements one project and product at the time but having an ASPICE maturity helps 26262: Much more focus on technical practices to ensure safety ASPICE only talks about generic requirements Requirements on traceability are stronger in ASPICE than in ASPICE is a small standard (SW arch: less than 2 + 0,5 = 2,5 pages), is large (SW arch: (App D) + 10 (part 9) = 18 pages) Much overlap, e.g. architecture 3

4 Why is documenting the SW arch difficult? SW developers are not used to documenting the architecture How to combine with agile development? How to incorporate all Safety documentation? Maintaining the documentation Distinguish between System and Software level Level of detail Further to be discussed in workshop tomorrow! This only covers SW architecture SYSTEM is actually more interesting 4

5 Automotive SPICE (Version 3.0) HIS Scope Extended HIS Scope Previously Eng 1-10 Changes in Test structure 5

6 Related ASPICE processes System and Software Requirements System architecture Test strategy (from all test processes) Verification = Review Traceability 6

7 SW architecture work product Note duplication Same in 2.5 and 3.0 7

8 Automotive SPICE Reference Model 3.0 SWE.2 Software Architectural Design 8

9 SWE.2 Software Architectural Design Process Purpose: The purpose of the Software Architectural Design Process is to establish an architectural design and to identify which software requirements are to be allocated to which elements of the software, and to evaluate the software architectural design against defined criteria. Typical Challenges: 1. What level of details is needed 2. Find a healthy level of modules - identifying all necessary modules and interfaces 3. Creating an architecture that is flexible and adoptable to change 4. Finding balance between flexibility and performance lots of layers and indirection will makes things slower (important for embedded systems) 5. Evaluation criteria and recording design decisions 6. Traceability 7. Keeping the architecture documentation up-to-date 9

10 SWE.2 Software Architectural Design Base Practices: SWE.2.BP1: Develop software architectural design. Develop and document the software architectural design that specifies the elements of the software with respect to functional and non-functional software requirements. SWE.2.BP2: Allocate software requirements. Allocate the software requirements to the elements of the software architectural design. SWE.2.BP3: Define interfaces of software elements. Identify, develop and document the interfaces of each software element. SWE.2.BP4: Describe dynamic behavior. Evaluate and document the timing and dynamic interaction of software elements to meet the required dynamic behavior of the system. SWE.2.BP5: Define resource consumption objectives. Determine and document the resource consumption objectives for all relevant elements of the software architectural design on the appropriate hierarchical level. SWE.2.BP6: Evaluate alternative software architectures. Define evaluation criteria for architecture design. Evaluate alternative software architectures according to the defined criteria. Record the rationale for the chosen software architecture. SWE.2.BP7: Establish bidirectional traceability. Establish bidirectional traceability between software requirements and elements of the software architectural design. SWE.2.BP8: Ensure consistency. Ensure consistency between software requirements and the software architectural design. SWE.2.BP9: Communicate agreed software architectural design. Communicate the agreed software architectural design and updates to software architectural design to all relevant parties. 10

11 04-04 Software architectural design overall software structure operative system including task structure Identifies inter-task/inter-process communication the required software elements own developed and supplied code the relationship and dependency between software elements where the data (such as parameters) are stored and which measures (e.g. checksums, redundancy) are taken to prevent data corruption variants for different model series or configurations are derived dynamic behavior of the software (Startup, shutdown, software update, error handling and recovery, etc.) which data is persistent and under which conditions Consideration is given to: - any required software performance characteristics - any required software interfaces - any required security characteristics required - any database design requirements 11

12 Traceability requirements 12

13 The whole SW impacts 13

14 Software level 14

15 7: Software architectural design Objectives 1. Develop a software architectural design that realizes the software safety requirements 2. Verify the software architectural design General Architecture 1:n Component 1:n Unit The software architectural design represents all software components and their interactions in a hierarchical structure. Static aspects, such as interfaces and data paths between all software components, as well as dynamic aspects, such as process sequences and timing behaviour are described. - NOTE The software architectural design is not necessarily limited to one microcontroller or ECU, and is related to the technical safety concept and system design. The software architecture for each microcontroller is also addressed by this chapter. In order to develop a software architectural design both software safety requirements as well as all non-safety-related requirements are implemented. The software architectural design provides the means to implement the software safety requirements and to manage the complexity of the software development. 15

16 7: Prerequisites safety plan (refined) in accordance with 5.5.1; design and coding guidelines for modelling and programming languages in accordance with 5.5.3; hardware-software interface specification in accordance with ISO :2011, 7.5.3; software safety requirements specification in accordance with 6.5.1; software verification plan (refined) in accordance with 6.5.3; and software verification report in accordance with Support information technical safety concept (see ISO :2011, 7.5.1); system design specification (see ISO :2011, 7.5.2); qualified software components available (see ISO :2011, Clause 12); tool application guidelines in accordance with 5.5.4; and guidelines for the application of methods (from external source). 16

17 Requirements and recommendations Use of appropriate notation Design considerations Design principles Identification of software units Design aspects Component categorization New/modified components Re-used components Allocation of Safety requirements ASIL of combined components Software partitioning (Annex D) Dependent failure analysis (Part 9: 7 Dependent failure analysis) Safety analysis (Part 9: 8 Safety analysis) Error detection Error handling New hazards Resource usage Architectural design verification 17

18 7.4.1 Notation and Considerations Notations for software architectural design Methods (Notations) A B C D 1a Informal b Semi-formal (also executable models) c Formal Informal: Power-point drawings Semi-formal: UML, SDL or UML-RT, An overview of architecture design notations Design considerations: During the development of the software architectural design the following shall be considered: a. the verifiability of the software architectural design; NOTE This implies bi-directional traceability between the software architectural design and the software safety requirements. (only safety requirements) b. the suitability for configurable software; c. the feasibility for the design and implementation of the software units; d. the testability of the software architecture during software integration testing; and e. the maintainability of the software architectural design. 18

19 7.4.3 Design principles Principles of software architecture design In order to avoid failures resulting from high complexity, the software architectural design shall exhibit the following properties by use of the principles listed in Table below: a. modularity; b. encapsulation, and c. simplicity. Methods A B C D 1a Hierarchical structure of software components b Restricted size of software components c Restricted size of interfaces d High cohesion within each software component e Restricted coupling between software components f Appropriate scheduling properties g Restricted use of interrupts (must have priority)

20 7.4.4 Level and Description The software architectural design shall be developed down to the level where all software units are identified The software architectural design shall describe: a. the static design aspects of the software components; i.e. - the software structure including its hierarchical levels; - the logical sequence of data processing; - the data types and their characteristics; - the external interfaces of the software components; - the external interfaces of the software; and - the constraints including the scope of the architecture and external dependencies. b. the dynamic design aspects of the software components, i.e. - the functionality and behaviour; (Note 2: including operating states e.g. power-up, shut-down, normal operation, calibration and diagnosis) - the control flow and concurrency of processes; (Note 3: including allocation to HW) - the data flow between the software components; - the data flow at external interfaces; and - the temporal constraints. 20

21 Reuse categorization Every safety-related software component shall be categorized as one of the following: a. newly developed; b. reused with modifications; or c. reused without modifications Safety-related software components that are newly developed or reused with modifications shall be developed in accordance with ISO Safety-related software components that are reused without modifications shall be qualified in accordance with ISO :2011, Clause

22 7.4.9 Req allocation and ASIL The software safety requirements shall be allocated to the software components. As a result, each software component shall be developed in compliance with the highest ASIL of any of the requirements allocated to it. - NOTE Following this allocation, further refinement of the software safety requirements can be necessary. Software components = one or more Software Units, thus we need to allocate safety reqs close to software units 22

23 Highest ASIL or no interference If the embedded software has to implement software components of different ASILs, or safety-related and non-safety-related software components, then all of the embedded software shall be treated in accordance with the highest ASIL, unless the software components meet the criteria for coexistence in accordance with ISO :2011, Clause 6. Freedom of interference general in ISO :2011, Clause 6. This means that cascading failures from this sub-element to the safety-related elements are absent. This can be achieved by design precautions such as those concerning the data flow and control flow for software, or the I/O signals and control lines for hardware. Software specific in Annex D (See separate slides) 23

24 Software Partitioning If software partitioning (see Annex D) is used to implement freedom from interference between software components it shall be ensured that: a) the shared resources are used in such a way that freedom from interference of software partitions is ensured; - NOTE 1 Tasks within a software partition are not free from interference among each other. - NOTE 2 One software partition cannot change the code or data of another software partition nor command non-shared resources of other software partitions. - NOTE 3 The service received from shared resources by one software partition cannot be affected by another software partition. This includes the performance of the resources concerned, as well as the rate, latency, jitter and duration of scheduled access to the resource. b) the software partitioning is supported by dedicated hardware features or equivalent means (this requirement applies to ASIL D, in accordance with 4.3); c) the part of the software that implements the software partitioning is developed in compliance with the same or an ASIL higher than the highest ASIL assigned to the requirements of the software partitions; and - NOTE In general the operating system provides or supports software partitioning. d) the verification of the software partitioning during software integration and testing (in accordance with Clause 10) is performed. 24

25 Dependent failures An analysis of dependent failures in accordance with ISO :2011, Clause 7, shall be carried out if the implementation of software safety requirements relies on freedom from interference or sufficient independence between software components. Part 9: Clause 7: Analysis of dependent failures Objective: The analysis of dependent failures aims to identify the single events or single causes that could bypass or invalidate a required independence or freedom from interference between given elements and violate a safety requirement or a safety goal. Architectural features to consider: - similar and dissimilar redundant elements; - different functions implemented with identical software or hardware elements; - functions and their respective safety mechanisms; - partitions of functions or software elements; - physical distance between hardware elements, with or without barrier; - common external resources. Independence is threatened by common cause failures and cascading failures, while freedom from interference is only threatened by cascading failures. (Detour) 25

26 Safety analysis Safety analysis shall be carried out at the software architectural level in accordance with ISO :2011, Clause 8, in order to: (next) identify or confirm the safety-related parts of the software; and support the specification and verify the efficiency of the safety mechanisms. NOTE Safety mechanisms can be specified to cover both issues associated with random hardware failures as well as software faults. 26

27 Error detection To specify the necessary software safety mechanisms at the software architectural level, based on the results of the safety analysis in accordance with , mechanisms for error detection as listed in Table 4 shall be applied. - NOTE When not directly required by technical safety requirements allocated to software, the use of software safety mechanisms is reviewed at the system level to analyse the potential impact on the system behaviour. Mechanisms for error detection A B C D 1a Range checks of input and output data b Plausibility check (reference model, comparing sources) c Detection of data errors (EDC, multiple storage) d External monitoring facility (watchdog) o e Control flow monitoring o f Diverse software design o o

28 Error handling This subclause applies to ASIL (A), (B), C and D, in accordance with 4.3 ((X) = recommendation): to specify the necessary software safety mechanisms at the software architectural level, based on the results of the safety analysis in accordance with , mechanisms for error handling as listed in Table 5 shall be applied. - NOTE 1 When not directly required by technical safety requirements allocated to software, the use of software safety mechanisms is reviewed at the system level to analyse the potential impact on the system behaviour. - NOTE 2 The analysis at software architectural level of possible hazards due to hardware is described in ISO a Mechanisms for error handling A B C D Static recovery mechanism (forward and backward, blocks, repetition = reset HW and re-execute SW) b Graceful degradation (prioritizing functions) c Independent parallel redundancy o o d Correcting codes for data

29 New hazards If new hazards introduced by the software architectural design are not already covered by an existing safety goal, they shall be introduced and evaluated in the hazard analysis and risk assessment in accordance with the change management process in ISO :2011, Clause 8. - NOTE Newly identified hazards, not already reflected in a safety goal, are usually non-functional hazards. If those non-functional hazards are outside the scope of this standard then it is recommended that they be annotated in the hazard analysis and risk assessment with the following statement No ASIL is assigned to this hazard as it is not within the scope of ISO However, an ASIL is allowed for reference purposes. 29

30 Resource usage An upper estimation of required resources for the embedded software shall be made, including: a) the execution time; b) the storage space; and EXAMPLE RAM for stacks and heaps, ROM for program and non-volatile data. c) the communication resources. 30

31 Verification The software architectural design shall be verified in accordance with ISO :2011, Clause 9, and by using the software architectural design verification methods listed in Table 6 to demonstrate the following properties: compliance with the software safety requirements; compatibility with the target hardware; and - NOTE This includes the resources as specified in adherence to design guidelines. Methods for SW architecture design verification A B C D 1a Walk-through of the design ++ + o o 1b Inspection of the design c Simulation of dynamic parts of the design d Prototype generation o o e Formal verification o o + + 1f Control flow analysis g Data flow analysis

32 7: Work products Software architectural design specification resulting from requirements to 7.4.6, 7.4.9, , , and Safety plan (refined) resulting from requirement Software safety requirements specification (refined) resulting from requirement Safety analysis report resulting from requirement Dependent failures analysis report resulting from requirement Software verification report (refined) resulting from requirement ASPICE Output work products Software architectural design Software architectural design Software architectural design Interface requirement specification Software architectural design Software architectural design Review record Traceability record Communication record 32

33 Comparison ASPICE SWE.2.BP1: Develop software architectural design Notations for software architectural design Principles of software architecture design Required level Description (a: static) - (own and supplied code Arch doc) ASIL categorize of components (re-used) - (data consistency mechanisms Arch doc) and Software safety mechanisms Analyze new hazards SWE.2.BP2: Allocate software requirements Allocate software safety requirements ASIL analysis of components - (dependency analysis Arch doc) Software partitioning Dependent failure analysis SWE.2.BP3: Define interfaces of software elements SWE.2.BP4: Describe dynamic behavior Description (a: Interfaces) Description (b: dynamic) SWE.2.BP5: Define resource consumption objectives SWE.2.BP6: Evaluate alternative software architectures SWE.2.BP7: Establish bidirectional traceability SWE.2.BP8: Ensure consistency Resource limits - (7.4.2 Design considerations) Design considerations (a) Allocate software safety requirements Safety analysis SWE.2.BP9: Communicate agreed software architectural design Verify compliance, Design considerations 33

34 Excellent firms don't believe in excellence - only in constant improvement and change. In Search of Excellence - Tom Peters Even-Andre.Karlsson@addalot.se

Functional Safety and Safety Standards: Challenges and Comparison of Solutions AA309

Functional Safety and Safety Standards: Challenges and Comparison of Solutions AA309 June 25th, 2007 Functional Safety and Safety Standards: Challenges and Comparison of Solutions AA309 Christopher Temple Automotive Systems Technology Manager Overview Functional Safety Basics Functional

More information

Safety Argument based on GSN for Automotive Control Systems. Yutaka Matsubara Nagoya University

Safety Argument based on GSN for Automotive Control Systems. Yutaka Matsubara Nagoya University 1 Safety Argument based on GSN for Automotive Control Systems Yutaka Matsubara Nagoya University yutaka@ertl.jp 02.26.2014 2 Agenda 1. Safety argument in ISO26262 2. Requirements related to safety argument

More information

SOFTWARE QUALITY. MADE IN GERMANY.

SOFTWARE QUALITY. MADE IN GERMANY. UPCOMING IMPACT OF THE SECOND EDITION OF THE ISO 26262 MGIGroup, 11.07.2017 SOFTWARE QUALITY. MADE IN GERMANY. SOLUTIONS FOR INTEGRATED QUALITY ASSURANCE OF EMBEDDED SOFTWARE MOTIVATION Release ISO 26262:2011

More information

Deriving safety requirements according to ISO for complex systems: How to avoid getting lost?

Deriving safety requirements according to ISO for complex systems: How to avoid getting lost? Deriving safety requirements according to ISO 26262 for complex systems: How to avoid getting lost? Thomas Frese, Ford-Werke GmbH, Köln; Denis Hatebur, ITESYS GmbH, Dortmund; Hans-Jörg Aryus, SystemA GmbH,

More information

Failure Diagnosis and Prognosis for Automotive Systems. Tom Fuhrman General Motors R&D IFIP Workshop June 25-27, 2010

Failure Diagnosis and Prognosis for Automotive Systems. Tom Fuhrman General Motors R&D IFIP Workshop June 25-27, 2010 Failure Diagnosis and Prognosis for Automotive Systems Tom Fuhrman General Motors R&D IFIP Workshop June 25-27, 2010 Automotive Challenges and Goals Driver Challenges Goals Energy Rising cost of petroleum

More information

Is This What the Future Will Look Like?

Is This What the Future Will Look Like? Is This What the Future Will Look Like? Implementing fault tolerant system architectures with AUTOSAR basic software Highly automated driving adds new requirements to existing safety concepts. It is no

More information

Certified Automotive Software Tester Sample Exam Paper Syllabus Version 2.0

Certified Automotive Software Tester Sample Exam Paper Syllabus Version 2.0 Surname, Name: Gender: male female Company address: Telephone: Fax: E-mail-address: Invoice address: Training provider: Trainer: Certified Automotive Software Tester Sample Exam Paper Syllabus Version

More information

Automated Freedom from Interference Analysis for Automotive Software

Automated Freedom from Interference Analysis for Automotive Software Automated Freedom from Interference Analysis for Automotive Software Florian Leitner-Fischer ZF TRW 78315 Radolfzell, Germany Email: florian.leitner-fischer@zf.com Stefan Leue Chair for Software and Systems

More information

Safety and Reliability of Software-Controlled Systems Part 14: Fault mitigation

Safety and Reliability of Software-Controlled Systems Part 14: Fault mitigation Safety and Reliability of Software-Controlled Systems Part 14: Fault mitigation Prof. Dr.-Ing. Stefan Kowalewski Chair Informatik 11, Embedded Software Laboratory RWTH Aachen University Summer Semester

More information

LATEST ISO UPDATE Focusing on Concurrency. Heiko Doerr MGI Group, 06. December 2016

LATEST ISO UPDATE Focusing on Concurrency. Heiko Doerr MGI Group, 06. December 2016 LATEST ISO 26262 UPDATE Focusing on Concurrency Heiko Doerr MGI Group, 06. December 2016 STARTING POINT ISO 26262 released in November 2011 Second edition available for review as ISO/DIS 26262:2018 Final

More information

A Model-Based Reference Workflow for the Development of Safety-Related Software

A Model-Based Reference Workflow for the Development of Safety-Related Software A Model-Based Reference Workflow for the Development of Safety-Related Software 2010-01-2338 Published 10/19/2010 Michael Beine dspace GmbH Dirk Fleischer dspace Inc. Copyright 2010 SAE International ABSTRACT

More information

AUTOBEST: A microkernel-based system (not only) for automotive applications. Marc Bommert, Alexander Züpke, Robert Kaiser.

AUTOBEST: A microkernel-based system (not only) for automotive applications. Marc Bommert, Alexander Züpke, Robert Kaiser. AUTOBEST: A microkernel-based system (not only) for automotive applications Marc Bommert, Alexander Züpke, Robert Kaiser vorname.name@hs-rm.de Outline Motivation AUTOSAR ARINC 653 AUTOBEST Architecture

More information

Tool Qualification Plan for Testwell CTC++

Tool Qualification Plan for Testwell CTC++ Tool Qualification Plan for Testwell CTC++ Version: 0.8 Date: 2014-11-17 Status: Author: File: Size: Generic / Adapted / Presented / Generated / Reviewed / Final Dr. Martin Wildmoser, Dr. Oscar Slotosch

More information

ISO meets AUTOSAR - First Lessons Learned Dr. Günther Heling

ISO meets AUTOSAR - First Lessons Learned Dr. Günther Heling ISO 26262 meets AUTOSAR - First Lessons Learned Dr. Günther Heling Agenda 1. ISO 26262 and AUTOSAR Two Basic Contradictions Top-Down vs. Reuse Concentration vs. Distribution 2. Approach Mixed ASIL System

More information

Requirements-driven Verification Methodology for Standards Compliance Serrie-justine Chapman (TVS)

Requirements-driven Verification Methodology for Standards Compliance Serrie-justine Chapman (TVS) Requirements-driven Verification Methodology for Standards Compliance Serrie-justine Chapman (TVS) in collaboration with Test and Verification Solutions Ltd Infineon Technologies UK ARTEMIS CRYSTAL project

More information

TCL. ASIL Level. Software. Automotive ISO Tool-Qualification. Safety Manual. Software for Safety-Related Automotive Systems

TCL. ASIL Level. Software. Automotive ISO Tool-Qualification. Safety Manual. Software for Safety-Related Automotive Systems Best Practice Guideline Software for Safety-Related Automotive Systems ISO 26262 Tool-Qualification Requirements TCL Tool Confidence Level Safety Manual ASIL Level Functional Safety Analysis & Classification

More information

Formal Verification and Automatic Testing for Model-based Development in compliance with ISO 26262

Formal Verification and Automatic Testing for Model-based Development in compliance with ISO 26262 Formal Verification and Automatic Testing for Model-based Development in compliance with ISO 26262 Is your software safe? Do you have evidence? 2 BTC Embedded Systems AG proprietary all rights reserved

More information

The Safe State: Design Patterns and Degradation Mechanisms for Fail- Operational Systems

The Safe State: Design Patterns and Degradation Mechanisms for Fail- Operational Systems The Safe State: Design Patterns and Degradation Mechanisms for Fail- Operational Systems Alexander Much 2015-11-11 Agenda About EB Automotive Motivation Comparison of different architectures Concept for

More information

CTFL -Automotive Software Tester Sample Exam Paper Syllabus Version 2.0

CTFL -Automotive Software Tester Sample Exam Paper Syllabus Version 2.0 Surname, Forename: Gender: male female Company address: Telephone: Fax: E-mail-address: Invoice address: Training provider: Trainer: CTFL -Automotive Software Tester Sample Exam Paper Syllabus Version

More information

Considerations in automotive embedded development Global Automotive Director Kiyo Uemura

Considerations in automotive embedded development Global Automotive Director Kiyo Uemura Considerations in automotive embedded development Global Automotive Director Kiyo Uemura Agenda 1. IAR Systems Introduction 2. Background & ISO 26262 3. Software Development at the software level 4. Supporting

More information

Communication Patterns in Safety Critical Systems for ADAS & Autonomous Vehicles Thorsten Wilmer Tech AD Berlin, 5. March 2018

Communication Patterns in Safety Critical Systems for ADAS & Autonomous Vehicles Thorsten Wilmer Tech AD Berlin, 5. March 2018 Communication Patterns in Safety Critical Systems for ADAS & Autonomous Vehicles Thorsten Wilmer Tech AD Berlin, 5. March 2018 Agenda Motivation Introduction of Safety Components Introduction to ARMv8

More information

Semantics-Based Integration of Embedded Systems Models

Semantics-Based Integration of Embedded Systems Models Semantics-Based Integration of Embedded Systems Models Project András Balogh, OptixWare Research & Development Ltd. n 100021 Outline Embedded systems overview Overview of the GENESYS-INDEXYS approach Current

More information

automatisiertensoftwaretests

automatisiertensoftwaretests FunktionaleSicherheitmit automatisiertensoftwaretests SOFTWARE CONSIDERATIONS IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICAION RTCA DO-178B RTCA Dynamisch& Statisch 0 Agenda Übersicht über Sicherheitsstandards

More information

Introducing a new temporal partitioning scheme to AUTOSAR OS

Introducing a new temporal partitioning scheme to AUTOSAR OS 8 th AUTOSAR Open Conference Introducing a new temporal partitioning scheme to AUTOSAR OS 29 th Oct., 2015 Hiroaki TAKADA Professor, Inst. of Innovation for Future Society, Nagoya Univ. Executive Director

More information

Autonomous Driving From Fail-Safe to Fail-Operational Systems

Autonomous Driving From Fail-Safe to Fail-Operational Systems Autonomous Driving From Fail-Safe to Fail-Operational Systems Rudolf Grave December 3, 2015 Agenda About EB Automotive Autonomous Driving Requirements for a future car infrastructure Concepts for fail-operational

More information

Chapter 4 Objectives

Chapter 4 Objectives Chapter 4 Objectives Eliciting requirements from the customers Modeling requirements Reviewing requirements to ensure their quality Documenting requirements for use by the design and test teams 4.1 The

More information

An Information Model for High-Integrity Real Time Systems

An Information Model for High-Integrity Real Time Systems An Information Model for High-Integrity Real Time Systems Alek Radjenovic, Richard Paige, Philippa Conmy, Malcolm Wallace, and John McDermid High-Integrity Systems Group, Department of Computer Science,

More information

Software Verification and Validation (VIMMD052) Introduction. Istvan Majzik Budapest University of Technology and Economics

Software Verification and Validation (VIMMD052) Introduction. Istvan Majzik Budapest University of Technology and Economics Software Verification and Validation (VIMMD052) Introduction Istvan Majzik majzik@mit.bme.hu Budapest University of Technology and Economics Dept. of Measurement and Information s Budapest University of

More information

Part 5. Verification and Validation

Part 5. Verification and Validation Software Engineering Part 5. Verification and Validation - Verification and Validation - Software Testing Ver. 1.7 This lecture note is based on materials from Ian Sommerville 2006. Anyone can use this

More information

Company: Valeo Powertrain Systems Business Company: Valeo Powertrain Systems Business

Company: Valeo Powertrain Systems Business Company: Valeo Powertrain Systems Business "La démarche «Building» appliquée à la Sûreté de Fonctionnement des onduleurs" Building strategy application to functional safety of inverters Hicham LAHBIL Amélie THIONVILLE Company: Valeo Powertrain

More information

ISO compliant verification of functional requirements in the model-based software development process

ISO compliant verification of functional requirements in the model-based software development process requirements in the model-based software development process Hans J. Holberg SVP Marketing & Sales, BTC Embedded Systems AG An der Schmiede 4, 26135 Oldenburg, Germany hans.j.holberg@btc-es.de Dr. Udo

More information

Learning objectives. Documenting Analysis and Test. Why Produce Quality Documentation? Major categories of documents

Learning objectives. Documenting Analysis and Test. Why Produce Quality Documentation? Major categories of documents Learning objectives Documenting Analysis and Test Understand the purposes and importance of documentation Identify some key quality documents and their relations Understand the structure and content of

More information

Fault-Injection testing and code coverage measurement using Virtual Prototypes on the context of the ISO standard

Fault-Injection testing and code coverage measurement using Virtual Prototypes on the context of the ISO standard Fault-Injection testing and code coverage measurement using Virtual Prototypes on the context of the ISO 26262 standard NMI Automotive Electronics Systems 2013 Event Victor Reyes Technical Marketing System

More information

Issues in Programming Language Design for Embedded RT Systems

Issues in Programming Language Design for Embedded RT Systems CSE 237B Fall 2009 Issues in Programming Language Design for Embedded RT Systems Reliability and Fault Tolerance Exceptions and Exception Handling Rajesh Gupta University of California, San Diego ES Characteristics

More information

Entwicklung zuverlässiger Software-Systeme, Stuttgart 30.Juni 2011

Entwicklung zuverlässiger Software-Systeme, Stuttgart 30.Juni 2011 Entwicklung zuverlässiger Software-Systeme, Stuttgart 30.Juni 2011 Tools and Methods for Validation and Verification as requested by ISO26262 1 Introduction ISO26262 ISO 26262 is the adaptation of IEC

More information

Requirements Engineering: Specification & Validation. Software Requirements and Design CITS 4401 Lecture 18

Requirements Engineering: Specification & Validation. Software Requirements and Design CITS 4401 Lecture 18 Requirements Engineering: Specification & Validation Software Requirements and Design CITS 4401 Lecture 18 The Problems of Requirements What goal(s) are we trying to satisfy? How do we identify the scope

More information

Quality Indicators for Automotive Test Case Specifications

Quality Indicators for Automotive Test Case Specifications Quality Indicators for Automotive Test Case Specifications Katharina Juhnke Daimler AG Group Research & MBC Development Email: katharina.juhnke@daimler.com Matthias Tichy Ulm University Institute of Software

More information

Taking the Right Turn with Safe and Modular Solutions for the Automotive Industry

Taking the Right Turn with Safe and Modular Solutions for the Automotive Industry Taking the Right Turn with Safe and Modular Solutions for the Automotive Industry A Time-Triggered Middleware for Safety- Critical Automotive Applications Ayhan Mehmet, Maximilian Rosenblattl, Wilfried

More information

Recommended Practice for Software Requirements Specifications (IEEE)

Recommended Practice for Software Requirements Specifications (IEEE) Recommended Practice for Software Requirements Specifications (IEEE) Author: John Doe Revision: 29/Dec/11 Abstract: The content and qualities of a good software requirements specification (SRS) are described

More information

By V-cubed Solutions, Inc. Page1. All rights reserved by V-cubed Solutions, Inc.

By V-cubed Solutions, Inc.   Page1. All rights reserved by V-cubed Solutions, Inc. By V-cubed Solutions, Inc. Page1 Purpose of Document This document will demonstrate the efficacy of CODESCROLL CODE INSPECTOR, CONTROLLER TESTER, and QUALITYSCROLL COVER, which has been developed by V-cubed

More information

Tools and Methods for Validation and Verification as requested by ISO26262

Tools and Methods for Validation and Verification as requested by ISO26262 Tools and for Validation and Verification as requested by ISO26262 Markus Gebhardt, Axel Kaske ETAS GmbH Markus.Gebhardt@etas.com Axel.Kaske@etas.com 1 Abstract The following article will have a look on

More information

ISO Compliant Automatic Requirements-Based Testing for TargetLink

ISO Compliant Automatic Requirements-Based Testing for TargetLink ISO 26262 Compliant Automatic Requirements-Based Testing for TargetLink Dr. Udo Brockmeyer CEO BTC Embedded Systems AG An der Schmiede 4, 26135 Oldenburg, Germany udo.brockmeyer@btc-es.de Adrian Valea

More information

INTERNATIONAL STANDARD

INTERNATIONAL STANDARD INTERNATIONAL STANDARD IEC 61508-7 First edition 2000-03 Functional safety of electrical/electronic/ programmable electronic safety-related systems Part 7: Overview of techniques and measures This English-language

More information

Functional Safety on Multicore Microcontrollers for Industrial Applications

Functional Safety on Multicore Microcontrollers for Industrial Applications Functional Safety on Multicore Microcontrollers for Industrial Applications Thomas Barth Department of Electrical Engineering Hochschule Darmstadt University of Applied Sciences Darmstadt, Germany thomas.barth@h-da.de

More information

Lecture 6: Requirements Engineering

Lecture 6: Requirements Engineering Lecture 6: Requirements Engineering Software System Design and Implementation ITCS/ITIS 6112/8112 001 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte

More information

BUILDING GOOD-QUALITY FUNCTIONAL SPECIFICATION MODEL

BUILDING GOOD-QUALITY FUNCTIONAL SPECIFICATION MODEL BUILDING GOOD-QUALITY FUNCTIONAL SPECIFICATION MODEL A few words on Samares Engineering Research and Consultancy on Systems Engineering Requirement engineering Model-Based Systems Engineering Co-simulation

More information

SRM ARTS AND SCIENCE COLLEGE SRM NAGAR, KATTANKULATHUR

SRM ARTS AND SCIENCE COLLEGE SRM NAGAR, KATTANKULATHUR SRM ARTS AND SCIENCE COLLEGE SRM NAGAR, KATTANKULATHUR 603203 DEPARTMENT OF COMPUTER SCIENCE & APPLICATIONS QUESTION BANK (2017-2018) Course / Branch : M.Sc-CST Semester / Year : Even / II Subject Name

More information

Advanced Software Engineering: Software Testing

Advanced Software Engineering: Software Testing Advanced Software Engineering: Software Testing COMP 3705(L4) Sada Narayanappa Anneliese Andrews Thomas Thelin Carina Andersson Web: http://www.megadatasys.com Assisted with templates News & Project News

More information

The Analysis and Proposed Modifications to ISO/IEC Software Engineering Software Quality Requirements and Evaluation Quality Requirements

The Analysis and Proposed Modifications to ISO/IEC Software Engineering Software Quality Requirements and Evaluation Quality Requirements Journal of Software Engineering and Applications, 2016, 9, 112-127 Published Online April 2016 in SciRes. http://www.scirp.org/journal/jsea http://dx.doi.org/10.4236/jsea.2016.94010 The Analysis and Proposed

More information

Industrial Embedded Systems - Design for Harsh Environment -

Industrial Embedded Systems - Design for Harsh Environment - Industrial Embedded Systems - Design for Harsh Environment - Dr. Alexander Walsch alexander.walsch@ge.com Part VI WS 2012/13 Technical University Munich (TUM) SW Design Approach Identify standards (coding,

More information

TSW Reliability and Fault Tolerance

TSW Reliability and Fault Tolerance TSW Reliability and Fault Tolerance Alexandre David 1.2.05 Credits: some slides by Alan Burns & Andy Wellings. Aims Understand the factors which affect the reliability of a system. Introduce how software

More information

Software integration challenge multi-core experience from real world projects

Software integration challenge multi-core experience from real world projects Software integration challenge multi-core experience from real world projects Rudolf Grave 17.06.2015 Agenda About EB Automotive Motivation Constraints for mapping functions to cores AUTOSAR & MultiCore

More information

Computer-Based Control System Safety Requirements

Computer-Based Control System Safety Requirements Computer-Based Control System Safety Requirements International Space Station Program Revision B November 17, 1995 National Aeronautics and Space Administration International Space Station Program Johnson

More information

Design Concepts and Principles

Design Concepts and Principles Design Concepts and Principles Analysis to Design Data Object Description Entity- Relationship Diagram Data Flow Diagram Process Specification (PSPEC) Component level design (or) procedural design Data

More information

Frequently Asked Questions. AUTOSAR C++14 Coding Guidelines

Frequently Asked Questions. AUTOSAR C++14 Coding Guidelines Frequently Asked Questions AUTOSAR C++14 Coding Guidelines General Q: What is AUTOSAR? A: AUTOSAR (AUTomotive Open System ARchitecture) is a partnership of over 180 automotive manufacturers, automotive

More information

Product Information Embedded Operating Systems

Product Information Embedded Operating Systems Product Information Embedded Operating Systems Table of Contents 1 Operating Systems for ECUs... 3 2 MICROSAR.OS The Real-Time Operating System for the AUTOSAR Standard... 3 2.1 Overview of Advantages...

More information

Software Architecture. Definition of Software Architecture. The importance of software architecture. Contents of a good architectural model

Software Architecture. Definition of Software Architecture. The importance of software architecture. Contents of a good architectural model Software Architecture Definition of Software Architecture Software architecture is process of designing g the global organization of a software system, including: Dividing software into subsystems. Deciding

More information

Conformance Assertions, Test Scenarios, Test Cases, Conformity Assessment Report,

Conformance Assertions, Test Scenarios, Test Cases, Conformity Assessment Report, Conformance Assertions, Test Scenarios, Test Cases, Conformity Assessment Report, WG-31 Conformance, October 2017 Contents Overview Levels Verification structure Extending the content Physical test cases

More information

KESO Functional Safety and the Use of Java in Embedded Systems

KESO Functional Safety and the Use of Java in Embedded Systems KESO Functional Safety and the Use of Java in Embedded Systems Isabella S1lkerich, Bernhard Sechser Embedded Systems Engineering Kongress 05.12.2012 Lehrstuhl für Informa1k 4 Verteilte Systeme und Betriebssysteme

More information

Certified Information Systems Auditor (CISA)

Certified Information Systems Auditor (CISA) Certified Information Systems Auditor (CISA) 1. Domain 1 The Process of Auditing Information Systems Provide audit services in accordance with IT audit standards to assist the organization in protecting

More information

Automotive Functional Safety

Automotive Functional Safety Automotive Functional Safety Complexity, Confidence, Compliance, Certification Farmington, 2018-03-22 23.03.2018 150 years TÜV SÜD 150 years of inspiring trust Inspiring trust since 1866 The year 2016

More information

Certified Software Quality Engineer Preparation On Demand, Web-Based Course Offered by The Westfall Team

Certified Software Quality Engineer Preparation On Demand, Web-Based Course Offered by The Westfall Team Certified Software Quality Engineer (CSQE) Preparation course is an on demand, web-based course design to be a comprehensive, in-depth review of the topics in the ASQ s Certified Software Quality Engineer

More information

Workpackage WP2.5 Platform System Architecture. Frank Badstübner Ralf Ködel Wilhelm Maurer Martin Kunert F. Giesemann, G. Paya Vaya, H.

Workpackage WP2.5 Platform System Architecture. Frank Badstübner Ralf Ködel Wilhelm Maurer Martin Kunert F. Giesemann, G. Paya Vaya, H. Guidelines for application Deliverable n. D25.6 Guidelines for application Sub Project SP2 ADAS development platform Workpackage WP2.5 Platform System Architecture Tasks T2.5.4 Guidelines for applications

More information

Click ISO to edit Master title style Update on development of the standard

Click ISO to edit Master title style Update on development of the standard Click ISO 26262 to edit Master title style Update on development of the standard Dr David Ward Head of Functional Safety January 2016 Agenda Why update ISO 26262? What is the process for updating the standard?

More information

VDE Testing and Certification Institute

VDE Testing and Certification Institute Test Report Report No.... : 223766-AS6-1 File No.... : 5007383-4970-0007/223766 Date of issue... : 2016-04-28 Laboratory... : Testing and Certification Institute Address... : Merianstrasse 28 63069 Offenbach/Main;

More information

Guidelines for deployment of MathWorks R2010a toolset within a DO-178B-compliant process

Guidelines for deployment of MathWorks R2010a toolset within a DO-178B-compliant process Guidelines for deployment of MathWorks R2010a toolset within a DO-178B-compliant process UK MathWorks Aerospace & Defence Industry Working Group Guidelines for deployment of MathWorks R2010a toolset within

More information

SE 2730 Final Review

SE 2730 Final Review SE 2730 Final Review 1. Introduction 1) What is software: programs, associated documentations and data 2) Three types of software products: generic, custom, semi-custom Why is semi-custom product more

More information

Update on AADL Requirements Annex

Update on AADL Requirements Annex Open-PEOPLE Open Power and Energy Optimization PLatform and Estimator Update on AADL Requirements Annex Dominique BLOUIN* *Lab-STICC, Université de Bretagne Sud, Lorient, FRANCE AADL Standards Meeting,

More information

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS SOFTWARE ENGINEERING

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS SOFTWARE ENGINEERING DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS 6403 - SOFTWARE ENGINEERING QUESTION BANK TWO MARKS UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT 1. What is software engineering? Software engineering

More information

Application Note. AC500-S Usage of AC500 Digital Standard I/Os in Functional Safety Applications up to PL c (ISO )

Application Note. AC500-S Usage of AC500 Digital Standard I/Os in Functional Safety Applications up to PL c (ISO ) Application Note AC500-S Usage of AC500 Digital Standard I/Os in Functional Safety Applications up to PL c (ISO 13849-1) Contents 1 Introduction 3 1.1 Purpose... 3 1.2 Document history... 4 1.3 Validity...

More information

Quality Software Requirements By J. Chris Gibson

Quality Software Requirements By J. Chris Gibson Quality Software Requirements By J. Chris Gibson The information contained within this document has been gathered from a variety of sources and practices observed by the development team at Protera Software

More information

Verification and Validation. Assuring that a software system meets a user s needs. Verification vs Validation. The V & V Process

Verification and Validation. Assuring that a software system meets a user s needs. Verification vs Validation. The V & V Process Verification and Validation Assuring that a software system meets a user s needs Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 19,20 Slide 1

More information

Checklist for Requirements Specification Reviews

Checklist for Requirements Specification Reviews Checklist for Requirements Specification Reviews Organization and Completeness o Are all internal cross-references to other requirements correct? o Are all requirements written at a consistent and appropriate

More information

Integration With the Business Modeler

Integration With the Business Modeler Decision Framework, J. Duggan Research Note 11 September 2003 Evaluating OOA&D Functionality Criteria Looking at nine criteria will help you evaluate the functionality of object-oriented analysis and design

More information

Friends, Romans, countrymen use your EARS & Improve your requirements

Friends, Romans, countrymen use your EARS & Improve your requirements Friends, Romans, countrymen use your EARS & Improve your requirements (Not from Julius Caesar by William Shakespeare ) siemens.co.uk Introduction I Work for Siemens within the Rail Automation business.

More information

Sample Exam Syllabus

Sample Exam Syllabus ISTQB Foundation Level 2011 Syllabus Version 2.9 Release Date: December 16th, 2017. Version.2.9 Page 1 of 46 Dec 16th, 2017 Copyright 2017 (hereinafter called ISTQB ). All rights reserved. The authors

More information

Certification Authorities Software Team (CAST) Position Paper CAST-25

Certification Authorities Software Team (CAST) Position Paper CAST-25 Certification Authorities Software Team (CAST) Position Paper CAST-25 CONSIDERATIONS WHEN USING A QUALIFIABLE DEVELOPMENT ENVIRONMENT (QDE) IN CERTIFICATION PROJECTS COMPLETED SEPTEMBER 2005 (Rev 0) NOTE:

More information

Foundations of Software Engineering

Foundations of Software Engineering Foundations of Software Engineering Lecture 9: Architecture Documentation, Patterns, and Tactics Christian Kaestner 1 Learning Goals Use notation and views to describe the architecture suitable to the

More information

Functional Safety on Multicore Microcontrollers for Industrial Applications. Thomas Barth (h-da) Prof. Dr.-Ing. Peter Fromm (h-da)

Functional Safety on Multicore Microcontrollers for Industrial Applications. Thomas Barth (h-da) Prof. Dr.-Ing. Peter Fromm (h-da) Functional Safety on Multicore Microcontrollers for Industrial Applications Thomas Barth (h-da) Prof. Dr.-Ing. Peter Fromm (h-da) Contents Functional Safety Multicore Motivation ISO13849 Implemented Software

More information

Seven Roadblocks to 100% Structural Coverage (and how to avoid them)

Seven Roadblocks to 100% Structural Coverage (and how to avoid them) Seven Roadblocks to 100% Structural Coverage (and how to avoid them) White Paper Structural coverage analysis (SCA also referred to as code coverage) is an important component of critical systems development.

More information

VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS6403 SOFTWARE ENGINEERING II year/ IV sem CSE (Regulation 2013) UNIT 1- SOFTWARE PROCESS AND PROJECT

More information

Product Range 3SL. Cradle -7

Product Range 3SL. Cradle -7 Cradle -7 From concept to creation... 3SL Product Range PRODUCT RANGE HIGHLIGHTS APPLIES TO AGILE AND PHASE PROJECTS APPLICATION LIFECYCLE MANAGEMENT REQUIREMENTS MANAGEMENT MODELLING / MBSE / SYSML /

More information

For presentation at the Fourth Software Engineering Institute (SEI) Software Architecture Technology User Network (SATURN) Workshop.

For presentation at the Fourth Software Engineering Institute (SEI) Software Architecture Technology User Network (SATURN) Workshop. For presentation at the Fourth Software Engineering Institute (SEI) Software Architecture Technology User Network (SATURN) Workshop. The authors can be reached at cb@mitre.org or ioannis @Mitre.org. In

More information

MARTE Based Modeling Tools Usage Scenarios in Avionics Software Development Workflows

MARTE Based Modeling Tools Usage Scenarios in Avionics Software Development Workflows MARTE Based Modeling Tools Usage Scenarios in Avionics Software Development Workflows Alessandra Bagnato, Stefano Genolini Txt e-solutions FMCO 2010, Graz, 29 November 2010 Overview MADES Project and MADES

More information

Complexity-Reducing Design Patterns for Cyber-Physical Systems. DARPA META Project. AADL Standards Meeting January 2011 Steven P.

Complexity-Reducing Design Patterns for Cyber-Physical Systems. DARPA META Project. AADL Standards Meeting January 2011 Steven P. Complexity-Reducing Design Patterns for Cyber-Physical Systems DARPA META Project AADL Standards Meeting 24-27 January 2011 Steven P. Miller Delivered to the Government in Accordance with Contract FA8650-10-C-7081

More information

Safety and Security for Automotive using Microkernel Technology

Safety and Security for Automotive using Microkernel Technology Informationstag "Das Automobil als IT-Sicherheitsfall" Berlin, 11.05.2012 Safety and Security for Automotive using Microkernel Technology Dr.-Ing. Matthias Gerlach OpenSynergy TwoBirds withonestone Safety

More information

Contemporary Design. Traditional Hardware Design. Traditional Hardware Design. HDL Based Hardware Design User Inputs. Requirements.

Contemporary Design. Traditional Hardware Design. Traditional Hardware Design. HDL Based Hardware Design User Inputs. Requirements. Contemporary Design We have been talking about design process Let s now take next steps into examining in some detail Increasing complexities of contemporary systems Demand the use of increasingly powerful

More information

Implementation Architecture

Implementation Architecture Implementation Architecture Software Architecture VO/KU (707023/707024) Roman Kern ISDS, TU Graz 2017-11-15 Roman Kern (ISDS, TU Graz) Implementation Architecture 2017-11-15 1 / 54 Outline 1 Definition

More information

Embedded Systems Dr. Santanu Chaudhury Department of Electrical Engineering Indian Institute of Technology, Delhi

Embedded Systems Dr. Santanu Chaudhury Department of Electrical Engineering Indian Institute of Technology, Delhi Embedded Systems Dr. Santanu Chaudhury Department of Electrical Engineering Indian Institute of Technology, Delhi Lecture - 13 Virtual memory and memory management unit In the last class, we had discussed

More information

Verification Futures The next three years. February 2015 Nick Heaton, Distinguished Engineer

Verification Futures The next three years. February 2015 Nick Heaton, Distinguished Engineer Verification Futures The next three years February 2015 Nick Heaton, Distinguished Engineer Let s rewind to November 2011 2 2014 Cadence Design Systems, Inc. All rights reserved. November 2011 SoC Integration

More information

Improving Software Testability

Improving Software Testability Improving Software Testability George Yee, 1Z48-M Jan 14, 2000 1 Contents 1. Introduction 2. Improving Testability at Design Time 3. Improving Testability at Coding Time 4. Putting it into Practice 5.

More information

Compatible Qualification Metrics for Formal Property Checking

Compatible Qualification Metrics for Formal Property Checking Munich - November 18, 2013 Formal Property Checking Senior Staff Engineer Verification Infineon Technologies Page 1 Overview Motivation Goals Qualification Approaches Onespin s Coverage Feature Certitude

More information

Refresher: Lifecycle models. Lecture 22: Moving into Design. Analysis vs. Design. Refresher: different worlds. Analysis vs. Design.

Refresher: Lifecycle models. Lecture 22: Moving into Design. Analysis vs. Design. Refresher: different worlds. Analysis vs. Design. Analysis vs. Design Why the distinction? Design Processes Logical vs. Physical Design System vs. Detailed Design Architectures System Architecture Software Architecture Architectural Patterns (next lecture)

More information

On Design for Reliability

On Design for Reliability On Design for Reliability of Electronics in Nanosatellite Olga Mamoutova (presenter) Andrey Antonov Peter the Great St. Petersburg State Polytechnic University, Russia Dpt. of Computer Systems & Software

More information

XIV. The Requirements Specification Document (RSD)

XIV. The Requirements Specification Document (RSD) XIV. The Requirements Specification Document (RSD) What is a RSD? What to include/not include in a RSD? Attributes of a Well-Written RSD Organization of a RSD Sample Table of Contents An Example 2002 John

More information

18-642: Requirements

18-642: Requirements 18-642: Requirements 2/12/2018 "In spite of appearances, people seldom know what they want until you give them what they ask for. " - Gerald M. Weinberg - Donald Gause and Gerald Weinberg, Are Your Lights

More information

Engineering of Reliable Software Systems

Engineering of Reliable Software Systems Engineering of Reliable Software Systems Compliance of functional and non functional requirements of embedded bdddsystems by model driven software engineering Dipl.-Ing. Harald Hauff Prof. Dr. Hermann

More information

Test System Validation Guideline

Test System Validation Guideline Test System Validation Guideline This document is the guideline for the engineering process of demonstrating that a particular Test System meets the specified requirements according to the Bluetooth Specification.

More information

Review of Basic Software Design Concepts. Fethi Rabhi SENG 2021

Review of Basic Software Design Concepts. Fethi Rabhi SENG 2021 Review of Basic Software Design Concepts Fethi Rabhi SENG 2021 1 Topics The development process Planning Designing Implementing 2 1. The development process How to organise activities related to the creation,

More information

"Charting the Course... Certified Information Systems Auditor (CISA) Course Summary

Charting the Course... Certified Information Systems Auditor (CISA) Course Summary Course Summary Description In this course, you will perform evaluations of organizational policies, procedures, and processes to ensure that an organization's information systems align with overall business

More information