ACHIEVING FUNCTIONAL SAFETY OF AUDI DYNAMIC STEERING USING A STRUCTURED DEVELOPMENT PROCESS
|
|
- Tabitha Burke
- 7 years ago
- Views:
Transcription
1 ACHIEVING FUNCTIONAL SAFETY OF AUDI DYNAMIC STEERING USING A STRUCTURED DEVELOPMENT PROCESS Dr Juergen Schuller* 1, Marnix Lannoije* 2, Dr Michael Sagefka* 3, Wolfgang Dick* 4, Dr Ralf Schwarz* 5 * 1 Audi AG, I/EF-25, Ingolstadt, Germany, phone: , juergenschuller@audide * 2 Audi AG, I/EF-25, Ingolstadt, Germany, phone: , marnixlannoije@audide * 3 Audi AG, I/EF-25, Ingolstadt, Germany, phone: , michaelsagefka@audide * 4 Audi AG, I/EF-25, Ingolstadt, Germany, phone: , wolfgangdick@audide * 5 Audi AG, I/EF-25, Ingolstadt, Germany, phone: , ralfschwarz@audide Abstract: Audi dynamic steering is a safety relevant electronic steering system In order to achieve functional safety for this system a structured development process including all safety process aspects and several support processes have been defined and installed Furthermore, the compliance of the implemented processes with the defined processes is strictly monitored by the internal quality assurance Additionally, an external assessor is accompanying the product development in order to assure the functional safety of the product according to the requirements of international safety standards Besides the enforcement of the processes, the challenge in this project is the coordination and monitoring of three suppliers together with the quality assurance and the external assessor Copyright 2006 IFAC Keywords: safety, quality, processes, process models, requirements analysis, chassis control 1 FUNCTIONAL SAFETY Today the complexity and integration of electronic systems is continuously increasing in automotive applications, thus potentially increasing the risk for system failure or system malfunction The goal of functional safety is to prevent hazards generated by an unintended behaviour of a system, thus decreasing the risk of system malfunction to an acceptable level 1 For these safety relevant failures this acceptable risk level is called safety integrity level (SIL) In the only valid generic standard for functional safety (IEC 61508, 1998) four levels of safety integrity are defined, each being assigned a specific failure rate (failures per hour) The safety integrity level of a system is determined with a risk analysis and is a function of the degree of damage caused by the failure, the probability of occurrence and the controllability of the system failure The safety integrity measures which have to 1 This level is not an absolute number but depends on the system and on social standards The society usually accepts that technical systems fail at a certain (low) rate and cause damage without refusing to make use of the technique be implemented depend on the evaluated safety integrity level and are increasing with a higher SIL The safety integrity measures which are required in (IEC 61508, 1998) can be divided in 3 categories: functional safety management, development processes and product requirements for hardware and software architecture and safety integrity In this paper we will focus on the development processes In a letter to VdTÜV 2 (dated April 28, 2004), the VDA 3 stated that the generic standard for functional safety (IEC 61508, 1998) is not fully applicable for automotive industry, thus making it necessary to develop an application specific standard Until the availability of the automotive standard, the generic standard (IEC 61508, 1998) can be only partially applied for the development of safety relevant automotive systems This paper shows the adaptation of the normative process requirements to a safety relevant automotive system development 2 German Association of Technical Inspection Agencies 3 German Association of Automotive Industry 67
2 2 AUDI DYNAMIC STEERING 21 System functionality The principle of Audi dynamic steering is to superimpose an electronically controlled angle to the steering wheel angle in order to realise the following basic functionalities: increase steering comfort and vehicle handling at lower speeds by reducing the necessary steering wheel angle input of the driver and increase the driving safety at higher speeds by increasing the necessary steering wheel angle input of the driver, thus making the vehicle behaviour more tolerant to driver errors These basic functionalities can be realised with an algorithm called variable steering ratio, which is a characteristic diagram depending on steering wheel angle input and vehicle speed Additionally, the stabilisation of the vehicle is achieved with the same principle before the Electronic Stability Program (ESP) engages This leads to a much more comfortable stabilisation (sometimes unnoticed by the driver) without deceleration, thus increasing the active safety of the vehicle 22 Safety integrity A risk analysis has been performed using (Schwarz, 2005) The safety integrity level for all functionalities described in section 21 has been determined to ASIL D 4 Unfortunately, the automotive specific standard for functional safety (Jung, 2005) is not published yet 5 ; thus the requirements, which are associated with this safety integrity level, are not fully defined and not released Thus, we have to refer to valid standard requirements of (IEC 61508, 1998) using a mapping of the automotive integrity levels to the standard safety integrity levels (ASIL D is similar to SIL 3) Since it is sometimes difficult to apply the generic standard (IEC 61508, 1998) to automotive systems, Audi decided to make use of the know-how of TÜV 6 in order to interpret and adapt the normative requirements for this system development fig 1; the electronically controlled orifice (ECO) adapts the hydraulic flow depending on the steering velocity generated by the driver and the dynamic steering system The basic functionalities are deployed on the SCU, whereas the stabilisation functions are deployed on the ESP, called ESP-DSA Audi is responsible for the whole system, whereas the suppliers are responsible for their delivered subsystem: SCU and actuator: ZF Lenksysteme GmbH; ESP-DSA: Robert Bosch GmbH; LWS: Leopold Kostal GmbH steering wheel angle SMLS system boundary Fig 1 System architecture of Audi dynamic steering 3 STRUCTURED DEVELOPMENT PROCESS The first step to a structured development process is the definition of a suitable process model Several process models are known in literature (Eckrich, et al, 2002; Jung, and Woltereck, 2003; Reinelt, and Krautstrunk, 2005a) and used in practice Also, (IEC 61508, 1998) proposes a process model for the safety life cycle of a product which consists of roughly four phases: concept, realisation, production and decommissioning Here, we will focus on the realisation phase and discuss the defined process model 31 Process model hydraulic SCU ESP- DSA CAN servotronic steering wheel torque LWS actuator torsion active bar steering angle wheel ECO angle For the realisation phase the well-known V-model from software engineering (ISO/IEC 12207, 1995) has been adapted to this system development, see Fig 2 DF 1 DRS 1 DF 2 DF DF 3 4 ESP- Basis DRS 2 wheel speed sensors CAN Yaw rate sensors wheel torque 23 System Architecture Audi dynamic steering consists of the steering wheel angle sensor (LWS), the steering control unit (SCU), part of the ESP (ESP-DSA) and the actuator, see 4 FAKRA (Automotive Standard Committee in the German Institute for Standardisation) proposes 4 automotive safety integrity levels (ASIL), namely A, B, C and D, where D is the highest level 5 The final draft has been submitted to the ISO board but is not expected to become a standard before end of Technical Inspection Agency Fig 2 Process model for the system development 68
3 The process model is subdivided into 7 process steps, where 6 process steps are performed at Audi and the implementation step at the suppliers It has to be noted, that the implementation step itself can again be understood as a sub process model, eg again a V-model Each process step is described with its inputs and outputs, the necessary activities to achieve the required outputs and the responsibilities for each activity and output respectively Thus from this process model following project roles can be easily deduced: system developer, system architect, subsystem/component developer, subsystem/component tester, integration tester and system tester From the functional safety point of view a further role is needed: the safety manager His role is described in section 44 together with the support process safety management The allocation of these roles to certain project members is done in the document project manual, which is part of the output of the support process project management (not described in detail here) Furthermore, this process model defines the documentation structure consisting of the outputs of every process step 7 : system requirement specification, system architecture specification, subsystem/component specification, subsystem/component test specifications, integration test specification, reports and system test specification and reports requirement during the system test phase The responsibility for the formulation and analysis of the system requirements is assigned to the system developer and the safety manager Outputs: The system requirement specification (SRS) contains all system requirements including the safety requirements Adjacent process phases: As can be seen in Fig 2, the following process phase is the system architecture design, which needs the system requirement specification as input It is well known that the system test on the opposite side of the V-Model also requires the SRS for the system test specification in order to refer each system test to a system requirement 33 Development model The process model described before is the basis for the implemented development model, which describes the whole realisation phase until the start of production: it is an iterative model using scaled versions of the process model in each iteration phase, see figure 3 Basically, early in the development the left side of the V-Model (specification phase) is emphasized whereas during the later development the right side (testing phase) is emphasized This development model is the basis for the release management since at the end of each iteration phase an official product release (PR1 to PR4 in fig 3) is made This process model is the basis for all engineering activities but also for a number of supporting processes as will be shown later 32 Example: system requirements analysis In this chapter the first process step of the process model is described The requirement analysis is the most important step, where the costliest errors are made Inputs: The inputs for this process step are delivered from the concept phase, which is not described in this paper The outputs of the concept phase are defined as: system concept and risk analysis Activities: In this phase the system requirements have to be formulated The safety requirements are part of the system requirements and can be easily identified by the requirement keys described later A good example for the derivation of safety requirements from risk and criticality analysis is shown in (Reinelt, et al, 2005b) Every requirement has to be formulated precisely: it has to contain objective criteria, which allow verifying the fulfilment of the 7 The documents mentioned here are only subsets of the whole documentation Fig 3 Iterative development model for the realisation phase using the process model from fig 2 4 SUPPORT PROCESSES According to (ISO/IEC 12207, 1995) following support processes have been defined and implemented: project management, configuration management, problem and change management, supplier management and quality assurance Additionally, following support processes have been defined and implemented: requirement management, release management, test management, quality management and 69
4 safety management All support processes are more or less dependent on the defined process and development model, which means that all processes had to be adapted to the model in fig 2 In this paper we will focus on some important aspects of requirement management, release management, quality assurance and safety management 41 Requirement management The goal of requirement management is to enable the tracking of every requirement through the whole development cycle until the final validation Here again a concept from software engineering was used: the requirement keys Every requirement, which was formulated in specifications, has been tagged with a unique requirement key The structure of such a requirement key is quite simple, see fig 4 Fig 4 Notation of the requirement keys Examples of the resulting keys can be seen in fig 5 This notation makes it possible to build a hierarchy of requirements starting from system level going down to component level, see fig 5 Thus, every specification step of the process model in fig 2 contains one level of requirements system requirement specification system design specification subsystem requirement specification REQ_ADS_ÜBERL: convert the evaluated superposition steering angle in motor angle REQ_ADS_SCU_ÜBERL1FKT1: controlled power drive of the motor REQ_ADS_SCU_ÜBERL1FKT11: the superposition steering angle is evaluated with the partial superposition angles of REQ_ADS_SCU_ÜBERL1FKT19: a motor angular speed of is required REQ_ADS_SCU_FS2FKT1: control of the locking mechanism REQ_ADS_SCU_FS1FKT11: automatic monitoring of the locking mechanism is required in order to REQ_ADS_ESP-ADS_STABI3FKT1: output of superposition steering angle to SCU Fig 5 Hierarchical structure of the requirements Here it has to be emphasized that because of the hierarchical structure, the requirement keys can be also modelled and tracked in the Failure Mode and Effects Analysis (FMEA) Due to the graphical representation of functional networks in the FMEA it is immediately obvious, which component requirements are deduced from which system requirements The further tracking of the requirements during the implementation phase have to be guaranteed by the suppliers Since the notation for the requirements is different at each supplier (sometimes automatically generated keys by a tool), either a mapping table has to be used or the original requirement keys have to be included in the supplier requirements 42 Release management The goal of release management is to plan and to control the defined system release levels in order to assure the completion of the product until the last release at least 6 month before the start of production The basis of this support process is the development model from fig 3 Release Plan: This plan contains the definition of the contents of the four release steps on system level Since all specifications use the requirement key notation the release plan is based on these keys In addition the release plan contains the desired test coverage, the interface implementation, the hardware maturity and the product and process documentation for every release level Delivery Plan: The delivery plans are deduced from the release plan and contain the necessary deliveries of each subsystem supplier for the four system release steps Again the delivery plans contain the subsystem requirements and their desired implementation level In addition the delivery plans contain the desired test coverage and the product and process documentation, which has to be delivered by the suppliers Release Protocol: This protocol emerges from the comparison of the achieved product maturity with the release and delivery plans for every release step The evaluation of the product maturity is documented in detail in check lists for the system and every subsystem The evaluation results are summarized in the release protocol and judged in a release meeting by the whole project team The outcome of the meeting is a signed release protocol, where the result may be: released without restrictions (with respect to the regarded release step); released with discrepancies (without restrictions, but there may be faulty or missing documentation or some minor, known errors in the software etc); release with restrictions (usually, these are functional or safety restrictions, which have to be documented in the release protocol); not released (eg in case of too many restrictions) 43 Quality assurance (IEC 61508, 1998) requires an implemented quality management system as a basis for the functional safety management and the assessment of functional safety Thus, a project independent quality assurance has to be installed, which monitors the internal processes The instruments of quality assurance are: a quality assurance plan, defining the tasks, 70
5 a quality assurance project schedule, planning the activities and resources, a quality monitoring plan, documenting the results of quality checks at certain milestones (before the release steps) and numerous check lists generating the quality check results for every work product and process in the quality monitoring plan The results of quality assurance are summarized, judged in the project team and documented in the release protocol for every release step Depending on the relevance of the discrepancies adequate measures have to be initiated in order to reach the defined quality level These measures are documented in an action plan which has to be fulfilled until the next quality check In addition, the independent quality assurance of the suppliers is supervised by the Audi quality assurance 8 The instruments are basically the same as mentioned above The quality monitoring plans are issued together with the suppliers before the delivery steps and are part of the product and process documentation, which is delivered by the suppliers for every release step In case of discrepancies necessary measures are documented in an action plan, which has to be fulfilled by the supplier until the next delivery Furthermore, the software processes of the suppliers are assessed by Audi quality assurance according to (ISO/IEC 12207, 1995) 44 Safety management The goal of safety management is to support the product development process with respect to safety aspects All safety management activities 9 are summarized in the project safety plan, whereas the product safety activities are integrated in the development process documents described in section 31 (IEC 61508, 1998) also requires an independent assessment of functional safety, where the level of independency is a function of the safety integrity level For this system development an external assessor is required; this assessment is also part of the safety management process and is described in the safety plan The responsibility for the whole safety management is assigned to the project safety manager, who has to conduct the following activities: formulate all safety management activities in the safety plan, coordinate all internal and external safety activities 8 This activity is more part of the support process supplier management but is mentioned in this context because the external assessor of functional safety relies on these quality check results 9 Here all project specific activities are meant, whereas the project independent safety activities are described in the functional safety management system, which is not described in this paper organize the external assessment and provide all information for the external assessor Additionally, the safety manager is responsible for product safety activities during development: conduct a system risk analysis, formulate safety and safety integrity requirements in the system requirement specification, coordinate all safety analyses like FMEA, FTA, and FMEDA etc, monitor the completion of all measures defined in FMEA, supervise the fulfilment of safety requirements by component and system tests, communicate all safety requirements to the suppliers and assess changes in product requirements or implementation during development with respect to their safety relevance 5 CONCLUSION The intention of this paper is to give an overview about the processes and methods which have been defined and implemented for the development of Audi dynamic steering in order to achieve functional safety for the system It turned out that with pragmatic, sometimes simple methods a lot of the process requirements of (IEC 61508, 1998) can be achieved, eg: requirements management (with req keys) leads to the mandatory traceability; release management leads to planning reliability and commitment; safety management guarantees the coordination of all safety activities at Audi and the suppliers Especially release management lead to accelerated implementation of all support and development processes because every release step reveals shortcomings of product or process transparently First successes of the structured development process can be acclaimed: the safety concept of the stabilisation subsystem had to be redesigned due to safety integrity requirements; two product release steps have been accomplished successfully; the system and subsystems safety concepts have been assessed through external assessor and proved their feasibility and potential to meet all functional safety requirements It could be shown that the requirements for achieving functional safety are not a burden but are very helpful and lead to more efficient development and to higher product quality and safety 71
6 REFERENCES Eckrich, M, M Pischinger, M Krenn, R Bartz and P Munnix (2002) Aktivlenkung Anforderungen an Sicherheitstechnik und Entwicklungsprozess In: 11 Aachener Kolloqium Fahrzeugund Motorentechnik 2002 (Wallentowitz, H (Ed)), p IKA, Aachen IEC (1998) Functional safety of E/E/PE safety-related systems IEC, Genève ISO/IEC (1995) Information Technology Software Life-Cycle Processes ISO, Genève Jung, C and M Woltereck (2003) Funktionssicherheitskonzept für verteilte Entwicklung sicherheitsrelevanter Systeme In: VDI-Bericht 1789: Elektronik im Kraftfahrzeug VDI, Baden-Baden Jung, C (2005): Stand des ISO-Standards zur Funktionalen Sicherheit für die Automobilindustrie In: Safetronic 2005 Sichere Software und Hardware im Automobil TÜV, München Reinelt, W and A Krautstrunk (2005a) Safety process for development of electronic steering systems SAE technical paper Reinelt, W, W Klier and G Reimann (2005b) Systemsicherheit des Active Front Steering Automobiltechnik, 1/2005 p Schwarz, J (2005): Risikoanalyse Verfahrensbeschreibung (Entwurf) FAKRA, Frankfurt 72
ASSESSMENT OF THE ISO 26262 STANDARD, ROAD VEHICLES FUNCTIONAL SAFETY
ASSESSMENT OF THE ISO 26262 STANDARD, ROAD VEHICLES FUNCTIONAL SAFETY Dr. Qi Van Eikema Hommes SAE 2012 Government/Industry Meeting January 25, 2012 1 Outline ISO 26262 Overview Scope of the Assessment
More informationELECTROTECHNIQUE IEC INTERNATIONALE 61508-3 INTERNATIONAL ELECTROTECHNICAL
61508-3 ª IEC: 1997 1 Version 12.0 05/12/97 COMMISSION CEI ELECTROTECHNIQUE IEC INTERNATIONALE 61508-3 INTERNATIONAL ELECTROTECHNICAL COMMISSION Functional safety of electrical/electronic/ programmable
More informationTÜ V Rheinland Industrie Service
TÜ V Rheinland Industrie Service Business Area: Automation / Functional Safety Contact Minsung Lee +82-2-860-9969 mailto : minsung.lee@kor.tuv.com Sales Account Manager for Functional Safety Fax +82-2-860-9862
More informationHow to Upgrade SPICE-Compliant Processes for Functional Safety
How to Upgrade SPICE-Compliant Processes for Functional Safety Dr. Erwin Petry KUGLER MAAG CIE GmbH Leibnizstraße 11 70806 Kornwestheim Germany Mobile: +49 173 67 87 337 Tel: +49 7154-1796-222 Fax: +49
More informationControlling Risks Safety Lifecycle
Controlling Risks Safety Lifecycle Objective Introduce the concept of a safety lifecycle and the applicability and context in safety systems. Lifecycle Management A risk based management plan for a system
More informationISO 26262 Functional Safety Draft International Standard for Road Vehicles: Background, Status, and Overview
ISO 26262 Functional Safety Draft International Standard for Road Vehicles: Background, Status, and Overview Barbara J. Czerny, Joseph D Ambrosio, Rami Debouk, General Motors Research and Development Kelly
More informationSafety Lifecycle illustrated with exemplified EPS
September 2012 Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C-Ware, the Energy Efficient Solutions logo, Kinetis, mobilegt, PowerQUICC, Processor Expert, QorIQ,
More informationTesting of safety-critical software some principles
1(60) Testing of safety-critical software some principles Emerging Trends in Software Testing: autumn 2012 Matti Vuori, Tampere University of Technology 27.11.2012 Contents 1/4 Topics of this lecture 6
More informationIEC 61508 Overview Report
IEC 61508 Overview Report A Summary of the IEC 61508 Standard for Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems exida Sellersville, PA 18960, USA +1-215-453-1720
More informationFunctional Safety and Automotive SW - Engineering Introduction ISO 26262 @ Daimler
Functional Safety and Automotive SW - Engineering Introduction ISO 26262 @ Daimler Dr. Juergen Schwarz Senior Manager Functional Safety & E/E - Processes WOCS 2012 September 27, 2012, Tokyo, Japan Overview
More informationAn integrated approach to implement system engineering and safety engineering processes: SASHA Project
An integrated approach to implement system engineering and safety engineering processes: SASHA Project Hycham Aboutaleb 1,2, Mohamed Bouali 1, Morayo Adedjouma 3, Emilia Suomalainen 1 1 Knowledge Inside,
More informationIntroduction of ISO/DIS 26262 (ISO 26262) Parts of ISO 26262 ASIL Levels Part 6 : Product Development Software Level
ISO 26262 the Emerging Automotive Safety Standard Agenda Introduction of ISO/DIS 26262 (ISO 26262) Parts of ISO 26262 ASIL Levels Part 4 : Product Development System Level Part 6 : Product Development
More informationHardware safety integrity Guideline
Hardware safety integrity Comments on this report are gratefully received by Johan Hedberg at SP Swedish National Testing and Research Institute mailto:johan.hedberg@sp.se Quoting of this report is allowed
More informationVersion: 1.0 Latest Edition: 2006-08-24. Guideline
Management of Comments on this report are gratefully received by Johan Hedberg at SP Swedish National Testing and Research Institute mailto:johan.hedberg@sp.se Quoting of this report is allowed but please
More informationImpact of Safety Standards to Processes and Methodologies. Dr. Herbert Eichfeld
Impact of Safety Standards to Processes and Methodologies Dr. Herbert Eichfeld Impact to Processes, Methodologies, Products Processes + New/changed role descriptions (e.g. safety manager) + Assignments
More informationFunctional Safety Management: As Easy As (SIL) 1, 2, 3
Functional Safety Management: As Easy As (SIL) 1, 2, 3 Abstract This paper outlines the need for planning in functional safety management. Recent events such as the Montara blowout and the Deepwater Horizon
More informationA System-safety process for by-wire automotive systems
A System-safety process for by-wire automotive systems Steer-by-wire and other by-wire systems (as defined in this article) offer many passive and active safety advantages. To help ensure these advantages
More informationof traffic accidents from the GIDAS database until 5 seconds before the first collision. This includes parameters to describe the environment data,
STANDARDIZED PRE-CRASH-SCENARIOS SCENARIOS IN DIGITAL FORMAT ON THE BASIS OF THE VUFO SIMULATION Dipl.-Math. A. Schubert*, Dipl.-Ing. (FH), M. Eng. C. Erbsmehl*, Dr.-Ing. L. Hannawald* *Verkehrsunfallforschung
More informationElektrobit (EB) Automotive Consulting Manage challenging automotive software projects
www.elektrobit.com Elektrobit (EB) Automotive Consulting Manage challenging automotive software projects EB Automotive Consulting Manage challenging automotive software projects The automotive industry
More informationIntelligent development tools Design methods and tools Functional safety
Intelligent development tools Design methods and tools Functional safety Flanders DRIVE Index: Flanders DRIVE 1 Importance of functional safety 2 Functional safety for mechatronic systems 4 Global functional
More informationHerstellerinitiative Software (OEM Initiative Software)
Herstellerinitiative Software (OEM Initiative Software) Dr. Michael Daginnus Volkswagen AG Wolfsburg Dr. Dieter Marx Porsche AG Weissach Dr. Ralf Belschner Daimler AG Sindelfingen Kai Barbehön BMW AG München
More informationSafety Requirements Specification Guideline
Safety Requirements Specification Comments on this report are gratefully received by Johan Hedberg at SP Swedish National Testing and Research Institute mailto:johan.hedberg@sp.se -1- Summary Safety Requirement
More informationCHASSIS - 4WD SYSTEM. Realizes stable start-off and acceleration performance
CH-66 CHASSIS - 4WD SYSTEM 4WD SYSTEM DESCRIPTION The 4WD system of the 06 RAV4 uses an active torque control 4WD system. It is a compact, lightweight, and high performance 4WD system that optimally controls
More informationDEDICATED TO SOLUTIONS. Automotive System and Software Development
DEDICATED TO SOLUTIONS Automotive System and Software Development ... PERFORMANCE ADVANTAGE BY KNOW-HOW AND INNOVATION ESG Partnership System Competence Progress For five decades, ESG has been one of the
More informationSelecting Sensors for Safety Instrumented Systems per IEC 61511 (ISA 84.00.01 2004)
Selecting Sensors for Safety Instrumented Systems per IEC 61511 (ISA 84.00.01 2004) Dale Perry Worldwide Pressure Marketing Manager Emerson Process Management Rosemount Division Chanhassen, MN 55317 USA
More informationDesign of automatic testing tool for railway signalling systems software safety assessment
Risk Analysis VI 513 Design of automatic testing tool for railway signalling systems software safety assessment J.-G. Hwang 1, H.-J. Jo 1 & H.-S. Kim 2 1 Train Control Research Team, Korea Railroad Research
More informationIEC 61508 Functional Safety Assessment. Project: K-TEK Corporation AT100, AT100S, AT200 Magnetostrictive Level Transmitter.
61508 SIL 3 CAPABLE IEC 61508 Functional Safety Assessment Project: K-TEK Corporation AT100, AT100S, AT200 Magnetostrictive Level Transmitter Customer: K-TEK Corporation Prairieville, LA USA Contract No.:
More informationForedragfor Den Norske Dataforening, den 08.10.2003
Foredragfor Den Norske Dataforening, den 08.10.2003 CMM, CMMI and ISO 15504 (SPICE) Bruk av modenhetsmodeller under programmvareutvikling, er det nøkkelen til suskess? Malte Foegen, Jürgen Richter IT Maturity
More informationISO 26262 Introduction
ISO 26262 Introduction Prof. Christian Madritsch 2012 Table of Contents Structure of ISO 26262 Management of Functional Safety Product Development System Level Product Development Hardware Level Product
More informationA System-Safety Process For By-Wire Automotive Systems
SAE TECHNICAL PAPER SERIES 2000-01-1056 A System-Safety Process For By-Wire Automotive Systems Sanket Amberkar, Joseph G. D Ambrosio and Brian T. Murray Delphi Automotive Systems Joseph Wysocki HRL Laboratories
More informationApplication Functional Safety IEC 61511
Application Functional Safety IEC 61511 Introduction Functional safety must be an integral part of the project execution if we shall succeed to make safe application program We can t test and audit safety
More informationSoftware in safety critical systems
Software in safety critical systems Software safety requirements Software safety integrity Budapest University of Technology and Economics Department of Measurement and Information Systems Definitions
More informationSoftware Production. Industrialized integration and validation of TargetLink models for series production
PAGE 24 EB AUTOMOTIVE Industrialized integration and validation of TargetLink models for series production Continuous Software Production The complexity of software systems in vehicles is increasing at
More informationPhysical to Functional Mapping with Mindmap Software
2006-01-3493 Physical to Functional Mapping with Mindmap Software Copyright 2006 SAE International Michael R Sevcovic International Truck and Engine Corporation ABSTRACT This paper describes how mind mapping
More informationQualifying Software Tools According to ISO 26262
Qualifying Software Tools According to ISO 26262 Mirko Conrad 1, Patrick Munier 2, Frank Rauch 3 1 The MathWorks, Inc., Natick, MA, USA mirko.conrad@mathworks.com 2 The MathWorks, SAS, Grenoble, France
More informationThe Role of CM in Agile Development of Safety-Critical Software
The Role of CM in Agile Development of Safety-Critical Software Tor Stålhane1, Thor Myklebust 2 1 Norwegian University of Science and Technology, N-7491, Trondheim, Norway 2 SINTEF ICT, Strindveien 2,
More informationSOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT
SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT Mar 31, 2014 Japan Aerospace Exploration Agency This is an English translation of JERG-2-610. Whenever there is anything ambiguous in this document, the original
More informationUniversity of Paderborn Software Engineering Group II-25. Dr. Holger Giese. University of Paderborn Software Engineering Group. External facilities
II.2 Life Cycle and Safety Safety Life Cycle: The necessary activities involving safety-related systems, occurring during a period of time that starts at the concept phase of a project and finishes when
More informationE/ECE/324/Rev.1/Add.12/Rev.7/Amend.4 E/ECE/TRANS/505/Rev.1/Add.12/Rev.7/Amend.4
6 December 2012 Agreement Concerning the adoption of uniform technical prescriptions for wheeled vehicles, equipment and parts which can be fitted and/or be used on wheeled vehicles and the conditions
More informationCompliance ow - managing the compliance of dynamic and complex processes
Loughborough University Institutional Repository Compliance ow - managing the compliance of dynamic and complex processes This item was submitted to Loughborough University's Institutional Repository by
More informationStability. Control. Maximum Safety. Electronic brake systems for motorcycles
Stability. Control. Maximum Safety. Electronic brake systems for motorcycles www.continental-automotive.com Electronic brake systems for motorcycles 2 Accelerate. Enjoy. Brake like a pro. Electronic brake
More informationV-Modell XT. Part 1: Fundamentals of the V-Modell
V-Modell XT Part 1: Fundamentals of the V-Modell THE V-MODELL XT IS PROTECTED BY COPYRIGHT. BUNDESREPUBLIK DEUTSCHLAND 2004. ALL RIGHTS RESERVED. COPYRIGHT RESERVED BUNDESREPUBLIK DEUTSCHLAND 2004.THE
More informationSafety compliance. Energy management. System architecture advisory services. Diagnostics. Network topologies. Physical and functional partitioning
Energy management Network topologies Physical and functional partitioning Safety compliance Diagnostics System architecture advisory services www.continental-corporation.com Why system architecture? 2
More informationA new system architecture for cooperative traffic centres - the sim TD field trial
19th ITS World Congress, Vienna, Austria, 22/26 October 2012 EU-00081 A new system architecture for cooperative traffic centres - the sim TD field trial Dr. Dirk Hübner 1, Dipl.-Ing. Gerd Riegelhuth 2
More informationSafety Integrated. SIMATIC Safety Matrix. The Management Tool for all Phases of the Safety Lifecycle. Brochure September 2010. Answers for industry.
SIMATIC Safety Matrix The Management Tool for all Phases of the Safety Lifecycle Brochure September 2010 Safety Integrated Answers for industry. Functional safety and Safety Lifecycle Management Hazard
More informationHow To Develop Software
Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which
More informationSIL in de praktijk (Functional Safety) 23.04.2015 - Antwerpen. 61508 Compliance of Actuators and Life Cycle Considerations. SAMSON AG Dr.
SIL in de praktijk (Functional Safety) 23.04.2015 - Antwerpen SAMSON AG Dr. Thomas Karte 61508 Compliance of Actuators and Life Cycle Considerations 2015-04-23 SAMSON AG Dr. Karte - 61508 Compliance of
More informationDr. Brian Murray March 4, 2011
Event that could lead to an accident GM Autonomy HAZARD 1 Q=6e-7 Event that could lead to a hazard Control to prevent HAZARDOUS EVENT 1 HAZARDOUS EVENT 1 HAZARD CONTROL 1 r=6e-008 Q=0.0006 Q=0.001 Q=0.001
More informationSafety and security related features in AUTOSAR
Safety and security related features in Dr. Stefan Bunzel Spokesperson (Continental) Co-Authors: S. Fürst, Dr. J. Wagenhuber (BMW), Dr. F. Stappert (Continental) Automotive - Safety & Security 2010 22
More informationFunctional Safety Management of the development process of safety related programmable electronic systems at Jaquet Technology Group
Functional Safety Management of the development process of safety related programmable electronic systems at Jaquet Technology Group Document type: Certification Report Client: Jaquet Technology Group
More information-Blue Print- The Quality Approach towards IT Service Management
-Blue Print- The Quality Approach towards IT Service Management The Qualification and Certification Program in IT Service Management according to ISO/IEC 20000 TÜV SÜD Akademie GmbH Certification Body
More informationWG 4 Benchmark paper. Standardization and Certification
WG 4 Benchmark paper Standardization and Certification Benchmark paper on the main requirements for the development of electromobility on a European and international scale Working Group 4 Standardization
More informationFrequently Asked Questions
Frequently Asked Questions The exida Certification Program Functional Safety (SIL) Cyber-Security V2 R3 June 14, 2012 exida Sellersville, PA 18960, USA, +1-215-453-1720 Munich, Germany, +49 89 4900 0547
More informationCrucial Role of ICT for the Reinvention of the Car
Joint EC / EPoSS / ERTRAC Expert Workshop 2011 Electric Vehicle System Integration and Architecture Crucial Role of ICT for the Reinvention of the Car Karl-Josef Kuhn Siemens Corporate Research and Technologies
More informationFunctional Safety with ISO 26262 Principles and Practice Dr. Christof Ebert, Dr. Arnulf Braatz Vector Consulting Services
Functional Safety with ISO 26262 Principles and Practice Dr. Christof Ebert, Dr. Arnulf Braatz Vector Consulting Services Welcome to the Webinar Functional Safety with ISO 26262 Webinar Part 1, Principles
More information2005-01-0785. Effective Application of Software Safety Techniques for Automotive Embedded Control Systems SAE TECHNICAL PAPER SERIES
2005-01-0785 SAE TECHNICAL PAPER SERIES Effective Application of Software Safety Techniques for Automotive Embedded Control Systems Barbara J. Czerny, Joseph G. D Ambrosio, Brian T. Murray and Padma Sundaram
More informationRequirements-driven Verification Methodology for Standards Compliance
Requirements-driven Verification Methodology for Standards Compliance Serrie-justine Chapman (TVS) serrie@testandverification.com Mike Bartley (TVS) mike@testandverification.com Darren Galpin (Infineon)
More informationIs your current safety system compliant to today's safety standard?
Is your current safety system compliant to today's safety standard? Abstract It is estimated that about 66% of the Programmable Electronic Systems (PES) running in the process industry were installed before
More informationPABIAC Safety-related Control Systems Workshop
Health and and Safety Executive PABIAC Safety-related Control Systems Workshop KEY STANDARDS FOR ELECTRICAL & FUNCTIONAL SAFETY OF PAPERMAKING MACHINES: APPLICATION & USE Steve Frost HM Principal Electrical
More informationSoftware Engineering Reference Framework
Software Engineering Reference Framework Michel Chaudron, Jan Friso Groote, Kees van Hee, Kees Hemerik, Lou Somers, Tom Verhoeff. Department of Mathematics and Computer Science Eindhoven University of
More informationReduce Medical Device Compliance Costs with Best Practices. mark.pitchford@ldra.com
Reduce Medical Device Compliance Costs with Best Practices mark.pitchford@ldra.com 1 Agenda Medical Software Certification How new is Critical Software Certification? What do we need to do? What Best Practises
More informationPart I. Introduction
Part I. Introduction In the development of modern vehicles, the infotainment system [54] belongs to the innovative area. In comparison to the conventional areas such as the motor, body construction and
More informationSoftware Development for Multiple OEMs Using Tool Configured Middleware for CAN Communication
01PC-422 Software Development for Multiple OEMs Using Tool Configured Middleware for CAN Communication Pascal Jost IAS, University of Stuttgart, Germany Stephan Hoffmann Vector CANtech Inc., USA Copyright
More informationAchieving Functional Safety with Global Resources and Market Reach
Achieving Functional Safety with Global Resources and Market Reach 0A 0B Burner management systems Combustion controls Electric vehicle components (on-board, off board) Electrosensitive equipment Elevator
More informationAutomatic Validation of Diagnostic Services
Development ProcessES Diagnostics Automatic Validation of Diagnostic Services For the first time, a fully automated test case generator has been introduced in diagnostics validation at General Motors Europe
More informationIntroduction CHAPTER 1
CHAPTER 1 Introduction Ever since the development of the first integrated circuits in the late 1950s the complexity of such devices doubled every 20 months. A development which has been anticipated by
More informationSafety Driven Design with UML and STPA M. Rejzek, S. Krauss, Ch. Hilbes. Fourth STAMP Workshop, March 23-26, 2015, MIT Boston
Safety Driven Design with UML and STPA M. Rejzek, S. Krauss, Ch. Hilbes System and Safety Engineering A typical situation: Safety Engineer System Engineer / Developer Safety Case Product 2 System and Safety
More informationImproving Interoperability in Mechatronic Product Developement. Dr. Alain Biahmou, Dr. Arnulf Fröhlich, Dr. Josip Stjepandic
International Conference on Product Lifecycle Management 1 Improving Interoperability in Mechatronic Product Developement Dr. Alain Biahmou, Dr. Arnulf Fröhlich, Dr. Josip Stjepandic PROSTEP AG Dolivostr.
More informationFrequently Asked Questions
Frequently Asked Questions The exida 61508 Certification Program V1 R8 October 19, 2007 exida Geneva, Switzerland Sellersville, PA 18960, USA, +1-215-453-1720 Munich, Germany, +49 89 4900 0547 1 Exida
More information(Refer Slide Time: 01:52)
Software Engineering Prof. N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture - 2 Introduction to Software Engineering Challenges, Process Models etc (Part 2) This
More informationFunctional Safety Hazard & Risk Analysis
Embedded - IC & Automation Fortronic Functional Safety Hazard & Risk Analysis MILANO - April, 23 rd 2013 CEFRIEL 2013; FOR DISCUSSION PURPOSES ONLY: ANY OTHER USE OF THIS PRESENTATION - INCLUDING REPRODUCTION
More informationWhat is Automotive Software Engineering? What is Automotive Software Engineering? What is Automotive Software Engineering?
Process models: Capability Maturity Model Integration (CMMI) Software Process Improvement and Capability Determination (SPICE) V-Model Standards: MISRA-C standard AUTOSAR Configuration management Product
More informationCreated by: Austin Davis Neel Iyer Darcie Jones Sascha Schwarz
EMGT 587 Systems Engineering Created by: Austin Davis Neel Iyer Darcie Jones Sascha Schwarz Table of Contents Introduction... 3 Operational Scenarios... 4 1. User sets and cancels cruise control:... 4
More informationRevas-Inast Public Results
Revas-Inast Public Results Project Set-up Vehicle dynamics server: state estimator Picture from Triphase Rapid prototyping software platform Active safety demonstrator Innovative sensors With support of
More informationCaterpillar Automatic Code Generation
SAE TECHNICAL PAPER SERIES 2004-01-0894 Caterpillar Automatic Code Generation Jeffrey M. Thate and Larry E. Kendrick Caterpillar, Inc. Siva Nadarajah The MathWorks, Inc. Reprinted From: Electronic Engine
More informationAutomotive CAE Integration.
WHITEPAPER Automotive CAE Integration.. 2010 AUDI AG BMW AG Daimler AG Dr. Ing. h. c. F. Porsche AG Volkswagen AG PROSTEP AG Automotive CAE Integration Addendum to Automotive CAE Integration: Requirements
More informationIBM Rational Rhapsody
IBM Rational Rhapsody IBM Rational Rhapsody Reference Workflow Guide Version 1.9 License Agreement No part of this publication may be reproduced, transmitted, stored in a retrieval system, nor translated
More informationSoftware Product Quality Practices Quality Measurement and Evaluation using TL9000 and ISO/IEC 9126
Software Practices Measurement and Evaluation using TL9000 and ISO/IEC 9126 Witold Suryn 1, Alain Abran 2, Pierre Bourque 3, Claude Laporte 4 Department of Electrical Engineering, École de Technologie
More informationIEC 61508 Functional Safety Assessment. ASCO Numatics Scherpenzeel, The Netherlands
IEC 61508 Functional Safety Assessment Project: Series 327 Solenoid Valves Customer: ASCO Numatics Scherpenzeel, The Netherlands Contract No.: Q09/04-59 Report No.: ASC 09-04-59 R003 V1 R3 61508 Assessment
More informationProcess Quality Manager Monitor and document process data. With ConnectedManufacturing Solutions by Bosch Software Innovations. Software Innovations
Process Quality Manager Monitor and document process data. With ConnectedManufacturing Solutions by Bosch Software Innovations. Software Innovations 2 Process Quality Manager Managing process data the
More informationVehicle Electronics. Services and Solutions to Manage the Complexity
Vehicle Electronics Services and Solutions to Manage the Complexity INNOVATIONS & DEVELOPMENT CYCLES Commercial vehicle manufacturers are experiencing a technological change. In addition to the rising
More informationThe Problem: Automotive safety recalls, Control Systems Diagnostics, Stability Control, Traction Control, Anti-lock Braking, Adaptive Cruise Control
AUTOPLUG: Remote Diagnostics Automotive Architecture for Control Software Safety Rahul Mangharam, Yash V. Pant and Truong X. Nghiem Department of Electrical & Systems Engineering University of Pennsylvania
More informationBuilding a Safety Case in Compliance with ISO 26262 for Fuel Level Estimation and Display System
Building a Safety Case in Compliance with ISO 26262 for Fuel Level Estimation and Display System Master Thesis in Intelligent Embedded Systems School of Innovation, Design and Engineering Mälardalen University
More informationUse Case Design for AdaptIVe
M. Koch, A. Butz & J. Schlichter (Hrsg.): Mensch und Computer 2014 Workshopband, München: Oldenbourg Wissenschaftsverlag, 2014, S. 199-204. Use Case Design for AdaptIVe Stefan Wolter 1, Johann Kelsch 2
More informationSOFTWARE QUALITY MANAGEMENT THROUGH IMPLEMENTATION OF SOFTWARE STANDARDS
4 th Int. Conf. CiiT, Molika, Dec.11-14, 2003 61 SOFTWARE QUALITY MANAGEMENT THROUGH IMPLEMENTATION OF SOFTWARE STANDARDS S. Grceva, Z. Zdravev Faculty for Education Goce Delcev, University of Sts. Cyril
More informationetamax space GmbH Company Presentation
etamax space GmbH Company Presentation Company Profile of etamax space Founded: 1997 in Braunschweig Legal form: GmbH Shareholders: ckc ag (49,5%), 2 managing directors Staff: 50 (06/2014) Turnover: >
More informationReducing Steps to Achieve Safety Certification
Reducing Steps to Achieve Safety Certification WP-01174-1.0 White Paper This white paper describes the successful steps in achieving certification for an FPGA implementation of an application certified
More informationThe automotive industry is making great efforts to improve. Uniform standards in software development are an important
Process Improvements in Software Development Optimizing software quality with SPICE The automotive industry is making great efforts to improve software quality. In this context the Embedded Software Components
More informationLecture Slides for Managing and Leading Software Projects. Chapter 1: Introduction
Lecture Slides for Managing and Leading Software Projects Chapter 1: Introduction developed by Richard E. (Dick) Fairley, Ph.D. to accompany the text Managing and Leading Software Projects published by
More informationProcess Indicators for Process Engineering (PIPE)
Chapter 10 Process Indicators for Process Engineering (PIPE) M. Schabacker and M. Gröpper 10.1 Introduction The campaign Process Indicators for Product Engineering (PIPE) of the companies CONTACT Software,
More informationReliability Block Diagram RBD
Information Technology Solutions Reliability Block Diagram RBD Assess the level of failure tolerance achieved RELIABIL ITY OPTIMIZATION System reliability analysis for sophisticated and large scale systems.
More informationProcesses for Software in Safety Critical Systems
This is a preprint of an article published in Software Process: Improvement and Practice, volume 6, issue 1, pp. 47-62, 2001, copyright John Wiley and Sons Ltd., 2001, http://www.interscience.wiley.com
More information3SL. Requirements Definition and Management Using Cradle
3SL Requirements Definition and Management Using Cradle November 2014 1 1 Introduction This white paper describes Requirements Definition and Management activities for system/product development and modification
More informationDevelopment of AUTOSAR Software Components within Model-Based Design
2008-01-0383 Development of AUTOSAR Software Components within Model-Based Design Copyright 2008 The MathWorks, Inc. Guido Sandmann Automotive Marketing Manager, EMEA The MathWorks Richard Thompson Senior
More informationRestructure of CIMO-Guide Part III Chapter 3 (Quality Management of Meteorological Observing Systems): Changes and Supplements
Restructure of CIMO-Guide Part III Chapter 3 (Quality Management of Meteorological Observing Systems): Changes and Supplements Dr. Rolf Gauert Deutscher Wetterdienst (DWD), German National Meteorological
More informationExecutive Master Program Electronic Systems Engineering & Management
Executive Master Program Electronic Systems Engineering & Management Technology + Management KIT University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association
More informationPublic trainings, In-house seminars, webinars Personal qualification on ISO 26262
AFSP AFSE FUNCTIONAL SAFETY AUTOMOTIVE TRAINING AND PERSONAL QUALIFICATION Public trainings, In-house seminars, webinars Personal qualification on ISO 26262 THE SGS GROUP SGS-TÜV GmbH THE EXPERTS is the
More informationRequirements Management
MS Excel / Word, and ReqIF Export / Import and Round-trip Medical & Automotive Requirements and Risk (FMEA, IEC 62304, IEC 61508, ISO 26262...) Enterprise Architect and Atlassian JIRA integration Requirements
More informationIntegration of Time Management in the Digital Factory
Integration of Time Management in the Digital Factory Ulf Eberhardt a,, Stefan Rulhoff b,1 and Dr. Josip Stjepandic c a Project Engineer, Daimler Trucks, Mannheim, Germany b Consultant, PROSTEP AG, Darmstadt
More information