Software Development and Quality Assurance for ...

Software Development and Quality Assurance for Automotive Applications ZUSYS-Tutorial BTU Cottbus

Agenda

System and Software Development Quality Assurance Examples

Agenda


Objectives

Overview to Development Process

Agenda

System and Software Development Functions and Software Development Process Development Tools

Quality Assurance Examples

Agenda



Objectives

Understanding the Interdependability of Automotive Functions

System realizes Functions Vehicle Stability

Vehicle Stability (e.g. ESC)

Engine + -

Gearbox

Battery

Differential

Generator Transmission Converter

Regeneration

E-Motor

Boosting

Load Point Shifting

Integrated Controller Strategy for Longitudinal & Lateral Control is needed

Example for two Functions Integration of Hybrid and Chassis Controls

DYMOLA Hybridantrie b

Hybrid Control SIMULINK

ESC Control SIMULINK

Virtual Driver IPGDriver

Functional Mock-up Prototype IPGCar

Road – Infrastructure – Traffic CarMaker

System with Design Conflict realizing different Functions Recuperation vs. Safety Load point shifting lead to braking torque at power off maneuver.

Integrated vehicle behavior evaluation with the functional mock-up prototype in real world driving maneuvers.

System Modeling, Integration and Simulation Study Interaction of conflicting objectives

System consists of Plants and Controllers Interaction of Plants and Controllers

Agenda



Lessons learned

Knowing how functions and features interact

Agenda



Objectives

Understand the influence of the technical and social requirements, especially of • Computer Improvements, and • Functional Safety

Computers in our World

Konrad Zuse with Helmuth Schreyer constructing the Z1 (about 1937) in the living room (!) of his parents in Berlin-Kreuzberg, Wrangelstraße 37

Where and with which functions are computers and software in use? Estimate the part of them that are obvouis and hidden?

Famous Computer Forecasts

I think there is a world market for maybe five computers. This forecast of Thomas Watson, president of IBM, in 1943 is however provably false.


Computers in the future may weigh no more than 1.5 tons.

The US magazin Popular Mechanics forecasting of the relentless march of science in 1949 is basically correct, nevertheless this seams somehow distorted in the age of smart phones.


There is no reason for any individual to have a computer in his home. In 1977, Ken Olsen, founder of Digital Equipment Corp., believed that computers would only be interesting for companies. The rise of the personal computer disabused him. His company was acquired at the end of the PC Manufacturer Compaq.


The time-consuming organization of paper in the office of the future will be replaced by information processing by computer. This prediction of the Palo Alto Research Center in the seventies shows that euphoria is not a good consultant: The paperless office has still not fully enforced.

First Software in BMW 7er: Bosch-Motronic (1979)

Car as a driving parallel computer

Premium Cars have up to 70 Electrical Control Units communicating via 5 bus systems.

Embedded and Mechatronical Systems Definition An embedded system is a computer system designed for specific control functions within a larger system, often with real-time computing constraints and not calculation focused. Source: Wikipedia. Embedding system (mechanic, hydraulic, electronic)

Analog hardware (actuator)

Software Digital hardware

Reactive System

Analog hardware (sensors)

Cars and Semiconductors 100GB

Memory

10GB Δ appr. 7 years

1GB

F01

P4

100MB E6x

PII

Gordon Moore Intel Founder

E65

10MB All 4 years: tenfold increase!

80486

1MB E38

68000

100kB PC RAM

10kB

Flash Memory

E32

6502

t

1980

1985

1990

1995

2000

2005

2010

2015

Computer Industry vs. Car Industry

if GM had kept up with the technology like the computer industry has, we would all be driving $25.00 cars that got 1,000 miles to the gallon.

Source: Wikipedia

If GM had developed technology like Microsoft, we would all be driving cars with the following characteristics : 1. 2. 3. 4.

For no reason whatsoever, your car would crash twice a day. You'd have to press the "Start" button to turn the engine off. The airbag system would say "Are you sure?" before going off. Occasionally, for no reason whatsoever, your car would lock you out and refuse to let you in until you simultaneously lifted the door handle, turned the key and grabbed hold of the radio antenna.

At a computer expo (COMDEX) 1998, Bill Gates reportedly compared the computer industry with the auto industry.

Software Development Software Crisis and Software Development Process Software crisis was a term used in the early days of computing science. The term was used to describe the impact of rapid increases in computer power and the complexity of the problems that could be tackled. In essence, it refers to the difficulty of writing correct, understandable, and verifiable computer programs. The roots of the software crisis are complexity, expectations, and change. A software development process […] is a structure imposed on the development of a software product. […] There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.

Source: Wikipedia.

Complexity of Software Development

Source: Wikipedia

What does it remind you to? Software Crisis!

Structuring of the software development

(Complex) software is hard to create and maintain. A plan helps to develope the software. This plan - the so-called process model divides the development process in manageable, temporary and limited phases. The software will be completed step by step.

Der Gordische Knoten Jean-Simon Berthélemy (1743 - 1811) Source: Wikipedia

Every step brings only minor modifications.

The actual development process is accompanied by the project management and quality assurance.

V-Model

The V-model is a graphical representation of the systems development lifecycle. It summarizes the main steps to be taken in conjunction with the corresponding deliverables within computerized system validation framework. Source: Wikipedia.

Functional Safety Hazards Causes and Examples: • Fatigue of material: Durability exhausted, poor material, … • Human failure: Failure to comply with instructions, fatigue, … • Failure in operation: Shipment, transport, installation, start of operation, … • Environmental conditions: Humidity, heat, cold, lightning, power supply, … • Erratic behavior of integrated devices: erratic programming, weak signal, …

Safety and Security Safety & Security (in German both: Sicherheit)

Functional Safety

Active Safety (avoiding)

Passive Safety (mitigating)

Security

• Functional safety is the part of the overall safety of a system operating correctly in response to its inputs, and its failure management

• Actively controlling and correcting safety functions

• Non-active interventing components or passive measures that reduce the effect of an unplanned event or series of events

• The protection of a system against undesired access or usage

• Features that operate automatically, in response to the system's state

• (!) There are safety-impacting security risks

Requirement / Technical Standard A requirement is a singular documented physical and functional need that a particular product or process must be able to perform. It is most commonly used in a formal sense in systems engineering, software engineering, or enterprise engineering. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organisation, internal user, or other stakeholder.

A technical standard is an established norm or requirement about technical systems. It is usually a formal document that establishes uniform engineering or technical criteria, methods, processes and practices. In contrast, a custom, convention, company product, corporate standard, etc. which becomes generally accepted and dominant is often called a de facto standard. Source: Wikipedia.

Families of Technical Standards Engineering Standards Quality Standards • ISO 12207 (SW-Process) • ISO 9000ff, ISO TS 16949 • German V-Model • VDA Part 3.1 and 4.ff Assessment Models • DIN EN 60300-2 (Reliability Management) • ISO 15504 (SPICE) • VDI 4001-10 (Technical Reliability) • Automotive SPICE • CMMI Specific Design Instructions • Harmonized VDA Electronic Throttle Safety Concept • Type Approval Regulations: ECE R13(H) Annex 18(8), ECE R79 Annex 6 Safety Standards • IEC 61508 (Meta-Standard) • ISO TR 15497: MISRA Guidelines • ECSS-E-40A (EU, Space) • RTCA DO-178B (Aerospace SW,) • RTCA DO-254 (Aerospace, HW) • NASA-GB-1740.13-96 (SW-Guidebook) • UK Def Stan 00-55 (Military) • IEC 60880 (SW in Nuclear Power Plants)

IEC 61508 Derivates • EN 5012x (Railway) • IEC 60601 1-4 (Medical) • IEC 61513 (Nuclear) • IEC 61511 (Process Industry) • ISO 26262 (Automotive)

IEC 61508 Functional Safety of Electrical / Electronic / Programmable Electronic Safety-related Systems (E/E/PE, or E/E/PES) IEC 61508 is an international standard of rules applied in industry. IEC 61508 is intended to be a basic functional safety standard applicable to all kinds of industry. It defines functional safety as: “part of the overall safety relating to the EUC (Equipment Under Control) and the EUC control system which depends on the correct functioning of the E/E/PE safety-related systems, other technology safety-related systems and external risk reduction facilities.”

The standard covers the complete safety life cycle, and may need interpretation to develop sector specific standards. It has its origins in the process control industry. Source: Wikipedia.

ISO 26262 Road vehicles - Functional safety ISO 26262 is a Functional Safety standard, titled "Road vehicles -- Functional safety". The standard ISO 26262 is an adaptation of the Functional Safety standard IEC 61508 for Automotive Electric/Electronic Systems.

ISO 26262 defines functional safety for automotive equipment applicable throughout the lifecycle of all automotive electronic and electrical safety-related systems. The first edition, published on 11 November 2011, is intended to be applied to electrical and/or electronic systems installed in "series production passenger cars" with a maximum gross weight of 3500kg. It aims to address possible hazards caused by the malfunctioning behaviour of electronic and electrical systems. The standard consists of 9 normative parts and a guideline for the ISO 26262 as the 10th part. Source: Wikipedia.

1. Vocabulary 2. Management of functional safety 2-6 Safety management during item development

4. Product development: system level

3. Concept phase 3-5 Item definition 3-6 Initiation of the safety lifecycle 3-7 Hazard analysis and risk assessment 3-8 Functional safety concept

2-7 Safety management after release for production

4-5 Initiation of product development at the system level 4-6 Specification of the technical safety requirements 4-7 System design

4-11 Release for production 4-10 Functional safety assessment 4-9 Safety validation

7. Production and operation 7-5 Production

7-5 Operation, service (maintenance and repair), and decommissioning

4-8 Item integration and testing

5. Product development: hardware level

6. Product development: software level

5-5 Initiation of product development at the hardware level 5-6 Specification of hardware safety requirements 5-7 Hardware design

6-5 Initiation of product development at the software level 6-6 Specification of software safety requirements

5-8 Hardware architectural metrics 5-9 Evaluation of violation of the safety goal due to random HW failures 5-10 Hardware integration and testing

6-8 Software unit design and implementation

6-7 Software architectural design

6-9 Software unit testing 6-10 Software integration and testing 6-11 Verification of software safety requirements

8. Supporting processes 8-5 Interfaces within distributed developments 8-6 Specification and management of safety requirements 8-7 Configuration management 8-8 Change management 8-9 Verification

8-10 Documentation 8-11 Qualification of software tools 8-12 Qualification of software components 8-13 Qualification of hardware components 8-14 Proven in use argument

9. ASIL-oriented and safety-oriented analyses 9-5 Requirements decomposition with respect to ASIL tailoring 9-6 Criteria for coexistence of elements

9-7 Analysis of dependent failures 9-8 Safety analyses

10. Guideline on ISO 26262 (informative)

Core processes

2-5 Overall safety management

Agenda



Lessons learned

Understand the influence of the technical and social requirements, especially of • Computer Improvements, and • Functional Safety

Agenda



Objectives

Overview on development tools Understand the role of these tools

How would you develop Software?

Source: dSPACE.

…101010010001001001001001001111100...

Workflow and Main Development Tools

Pantograph

1. Vocabulary 2. Management of functional safety 2-6 Safety management during item development

4. Product development: system level

3. Concept phase 3-5 Item definition 3-6 Initiation of the safety lifecycle 3-7 Hazard analysis and risk assessment 3-8 Functional safety concept

2-7 Safety management after release for production

4-5 Initiation of product development at the system level 4-6 Specification of the technical safety requirements 4-7 System design

4-11 Release for production 4-10 Functional safety assessment 4-9 Safety validation

7. Production and operation 7-5 Production

7-5 Operation, service (maintenance and repair), and decommissioning

4-8 Item integration and testing

5. Product development: hardware level

6. Product development: software level

5-5 Initiation of product development at the hardware level 5-6 Specification of hardware safety requirements 5-7 Hardware design

6-5 Initiation of product development at the software level 6-6 Specification of software safety requirements

5-8 Hardware architectural metrics 5-9 Evaluation of violation of the safety goal due to random HW failures 5-10 Hardware integration and testing

6-8 Software unit design and implementation

6-7 Software architectural design

6-9 Software unit testing 6-10 Software integration and testing 6-11 Verification of software safety requirements

8. Supporting processes 8-5 Interfaces within distributed developments 8-6 Specification and management of safety requirements 8-7 Configuration management 8-8 Change management 8-9 Verification

8-10 Documentation 8-11 Qualification of software tools 8-12 Qualification of software components 8-13 Qualification of hardware components 8-14 Proven in use argument

9. ASIL-oriented and safety-oriented analyses 9-5 Requirements decomposition with respect to ASIL tailoring 9-6 Criteria for coexistence of elements

9-7 Analysis of dependent failures 9-8 Safety analyses

10. Guideline on ISO 26262 (informative)

Core processes

2-5 Overall safety management

How to achieve functional safety? Avoiding and controlling faults! Measures in the development process

• Appointment of a safety manager • Planning of safety activities • Tests • Validation • Reviews

• Use of qualified tools

Measures to avoid faults

• Safety analysis • Impact analysis during modifications • FMEA, FTA, RBD, …

• Use of parts with low failure rate • Use of robust/well approved algorithms

Measures to control faults

• Redundant switch off • Checking of input parameters in sw units

Technical Measures in the product

Errors in Tool may lead to errors in Functions

Errors in Tool may lead to errors in Functions

Classification of Development Tool

Classification

Tool impact

Tool error detection

Tool confidence level

Qualification ASIL

Tool functions and their use cases

TI1

TD4 TD3 TD2 TD1

TCL4

TCL3

Table with qualification measures for TCL4


TI0 TCL2

TCL1

Source: FAKRA UAK Software 2009.


No qualification needed

Confidence in the use of tools

Increased confidence from use

Evaluation of the tool development process

Validation of the software tool

Development in accordance with a safety standard

Part 8: Supporting processes Chapter 11: Qualification of software tools 4. Requirements and recommendations Planning of qualification of a software tool  Table 2 — Qualification of software tools classified TCL4 Methods

ASIL

A

B

C

D

1a


++

++

+

o

1b

Evaluation of the development process

++

++

++

+

1c


+

+

++

++

1d

Development in compliance with a safety standarda

+

+

++

++

a

No safety standard is fully applicable to the development of software tools. Instead, a relevant subset of requirements of the safety standard can be selected.

 Table 3 —Qualification of software tools classified TCL3 Methods

ASIL A

B

C

D

1a


++

++

++

+

1b


++

++

++

++

1c


+

+

+

++

1d


+

+

+

++

a


Part 8: Supporting processes Chapter 11: Qualification of software tools

4. Requirements and recommendations Planning of qualification of a software tool  Table 4 — Qualification of software tools classified TCL2

Methods

ASIL A

B

C

D

1a


++

++

++

++

1b


++

++

++

++

1c


+

+

+

+

1d


+

+

+

+

a


Agenda



Lessons learned

Overview on development tools Understand the role of these tools

Agenda


Lessons learned

Overview to Development Process Overview on development tools Understand the role of these tools

Agenda


Agenda


Objectives

Understand the Approach VASE Understand the Quality Assurance by VASE

Agenda

System and Software Development Quality Assurance Validation Suite Approach Validation Suite Requirements Assessment steps of the Validation Suite

Examples

Agenda


Examples

Objectives

Overview and Understand the Approach VASE

Workflow and Main Development Tools

Basic Idea for Validation Suite EWt: Transformation of a model m by development tool EW to a binary Bt Sm: Set of stimuli for a model m M (= suitable models (i.e. EW Inputs)) Em: Set of possible results em for evaluations of model m evalx :evaluation function for an execution environment x

To be shown by VS for all Models and Stimuli:

distance d(em, em’) = 0

( em

Em; em’

Em’)

• Function d defines “Correctness” (here: Bit-Equality of all results). • “Teststrategy” defines required models and stimuli for the VS

Central Validation Suite Strategy 1. Automated testing and result evaluation of many tests • database with various models and stimuli • powerful automated test environment • efficient evaluation of result correctness • validity of validation results (incl. “golden results”) 2. State-Of-The-Art validation strategy: • evaluation of safety standards requirements • independent derivation: requirements for tools • independent derivation: requirements for VS • include tool requirements into VS • implement VS requirements

Typical Basic Structure of Validation Suite

State of the art requirements for VS

VS-Input: EW-TL-xxxx

VS User Manual (with Checklists) VS Maintenance Manual

VS

Review-Part Review Manual

Test-Part Test cases (Models, Stimuli, Configurations) Test scripts Test Environment

VS-Operating Environment HW (Evalboard, PC), OS, Tools

VS-Out: Qualification Report

Define Validation Suite Input early in Project Fix basic configuration of tool to be validated: 1. 2. 3. 4.

Operating Environment, Code generator incl. relevant Hooks, Compiler with Source files (if req.) Development guidelines

e.g. Windows, JAVA, MATLAB, TargetLink, Windriver, and Modelling Guidelines Document “EW-Def” (Tool Definition)





VS





Test Cases: Test Strategy

Quality Assurance Targets: Coverage Targets, Detection Rates

State of the art Requirements for VS

Tool Specifics: Modelling Language Structure

State of the art Testing Approaches For Compilers / Code Generators

Tool Specific Test Strategy 15 Test Fields in 9 Test Categories based on: - Language Structure and Combinatorics - Existing series-development Software Units / Unit Tests - Complementary Testing Approaches for Synthetic Test Cases: - Black Box Testing (based on language spec) - Grey Box Testing (Optimizations, Critical Sections of CodeGeneration Algorithms, Heuristically Common Defects in Compilers/Code-Generators) - Equivalence Testing (equiv. language constructs) - Random Testing (corner cases) - Regression Testing (known “fixed” defects) - Integration Testing of complete tool-chain: - Robustness / Repeatability / Integration Tests - Standards Adherence of output (C, Binary Code)

Test Cases: Automatic Test Generation State of the art Requirements for VS

Tool Specifics: Modelling Language Structure

State of the art Testing Approaches For Compilers / Code Generators

Test Strategy Manual Specification Executable Test Specifications (Isabelle / HOL + Extensions) Automatic: Test Case Generator

Raw Test Cases One TC: 1 Model + Multiple Sets of Synthetic Stimuli Automatic: Refernce Interpreter Final Test Cases One TC: 1 Model + Multiple Sets of Synthetic Stimuli + Reference Results

Test Cases: Reference Interpreter Full support of all valid TargetLink models in subset • Bit-accurate generation of reference values based on: • Language Specification, User Documentation • IEEE-754 Standard • Input from TL manufacturer on a few corner cases (e.g. constant scaling with tolerances, …) • Optional Support for HW-specific arithmetics: • non-IEEE FPUs (MPC 55xx, TC 179x, NEC V850) • Optional Support for certain tool limitations/peculiarities

• Fully diversified implementation in ANSI Common Lisp: • 15 KLoC ANSI CL, 30-40 % reusable for other code-gen • Dual CL implementations (SBCL, LispWorks) • Intel and PowerPC hardware • Windows, Mac OS X and Linux operating systems

Test Cases: Reference Interpreter Architecture •Basic support libraries for stimulus / model management •Core framework offers support for • Target-specific arithmetics • Typed arithmetic (fixed-point / floating-point) • Discrete-Time Semantics of TL Models •Block behaviour specification through embedded domain-specific language (DSL):





VS





Test Environment: thorough testing and analysis, certified in advance Reference Interpreter

Model +

References

Simulator

MIL results

C-Code Generator

?

Stimu li PC

C code +

SIL results

Target

PIL results

...0100110

001

101010010001001001001001001111100...

Result Analysis:

Bit-by-Bit comparison

Test Environment: Derivation of EW specific characteristics EW

Adaptions of VS and/or RefInt

test generation (manual, automated, …)

Loop… ...until all NOKs are assigned as Adaption of VS, RefInt or EW

VS-Developer Assignemet

EW Developer Independent Analysis

VASE Specifics EW

Results NOK PIL / RefInt deviate

ERR VS-Developer Analysis

Qualification Report

Specifiied tests VS-Test environment

Abbreviations VS … TargetLink-VS NOK … not OK ERR … Abort during Codegeneration

TestResults

OK

Most critical scenario: Erroneous code generated, despite: 1. 2. 3. 4.

Conformance to Modelling-Guidelines Confirmation by ES-Model-checkers Model preparation via TL-Tool chain Consideration of all notes from Log-file

EW





VS





Lessons learned

Overview and Understand the Approach VASE

Agenda


Examples

Objectives

Know the Requirements of Approach

Validation Requirements Potential Sources

Development Tools are complex: • potentially error prone • without evidence of integrity • without „proven history“ • they need validation prior use in safety related projects (e.g. ISO CD 26262 ) • No specific test criteria exist in standards

Considered Sources Evaluated Sources Considered Requirements Derived VS-Requirements

Task: Derive requirements • top-down-filtering process • derive and refinement existing requirements: • currently: “VS-Anforderungen V2.0” Result: 113 categorized requirements 7 • functional • non-functional 39

IEC 61508

7

IEC 615 ISO 26262

51 51

39

ISO 26

BMW Grob

BMW G

12

12 4

4

PTB

PTB

EXP

EXP

Validation Suite Requirements VS-Requirements V2.0 VS-Requirements

Derivation & Use Guideline

General structure of requirements: • •

… for VS for VS Main Test (= main part for test based VS) … for Pre Test of EW (= Annex; general suitability criteria for language and tool)

Structure of VS Requirements, with requirements on… 1. …Functionality of VS, e.g. test execution, logging of Configuration data 2. …Documentation and Report generation e.g. Generation of a tool Qualification Report 3. …Structure and Constituents of VS e.g. test database; different test categories with systematic tests test of language 4. …Validation of correct transformation of EW-Input e.g. for modular EW-Input 5. …Validation of intermediate code representations e.g. readability 6. …other Functional checks of the tool e.g. integration of other modules into the code 7. … Verification and Validation of VS itself e.g. structured and systematically planned V&V activities 8. … Qualität of VS itself e.g. Config. management; planning and execution of QA measures Structure of Requirements for pre test of tools: 1. Support on and facilitation of suitable tool-Input by tool 2. Basic properties of intermediate code representations (C) and tool-Output 3. Other functional properties of the tool 4. Tool quality

Lessons learned

Overview to the Requirements

Agenda


Examples

Objectives

Know the Assessment Steps

Structured stepwise procedure for VS-Assessment Test-Phase

Test object

1. Pre-Test (general suitability of tool)

EW Definition EW + Documentation EW-Developer (Audits)

e.g. tool allows suitable sw development (e.g. modularity)?

2. Test of VS Test-Engine (TAU) (suitability of VS Testenvironment)

TAU + Documentation TAU-Developer (Audits)

e.g. TAU logs all relevant data?

3. Test of VS Testcases

VS-Test strategy VS-Test plan VS-Test specification

Test categories for each language feature? …; for modular progr. building blocks?

VS-Documentation VS-Development, V&V VS-Developer Audits

Test cases generation and executions for language features; VS-V&V plan / Rep. …

(suitability of VS test case planning)

4. Main VS Test (suitability of VS as a whole)

Test aim

Derivation of compliance level for all VS requirement

Overall results of assessment activities: VS-TL-0001 complies satisfactory to the VS Requirements

•

The VS requirements • could be traced into the VS design • were refined for the VS • Have been successfully implemented to a large extend

•

The VS has been successfully applied to a TargetLink / WindRiver based tool chain EW-TL-0001 Several potential issues have been identified and suitably handled Nevertheless, overall the results have confirmed the suitability of the tool chain and maturity of the contained tools for intended use

• •

Agenda


Examples

Lessons learned

Understand the Assessment Steps

Agenda


Examples

Lessons learned

Understand the Approach VASE Understand the Quality Assurance by VASE

Agenda


Agenda


Objectives

Irregularities detected by Approach VASE

Experience with tool validation Sample problems discovered Important Note: The sample detected problems presented here

…are indications of – a thorough testing approach by the VS – comprehensive test database and test engine – with over 150.000.000 test result comparisons

!

The sample issues discovered – are typical for complex software tools (>> 100.000 LOC). – Similar issues can be found in most tools – Other tools may show up many more issues … The samples SHALL motivate tool validation The examples SHALL NOT be used to – question the maturity of the specific tested tool – question the general suitability of the tested tool

!

Agenda

System and Software Development Quality Assurance Examples Origin of Word Bug Incorrect Optimization Fused Multiply-Add / Subtract Sample Problem with Subtraction and Cast Wrong Rounding of Constants with MinMax Unexpected Behavior with SHIFT-Operations Other famous Bugs

Agenda


Locating Bugs Bugs in Development Tools

Bugs by Integration

Bugs from Application

Locating Bugs Bugs in Development Tools

Validation Suite Bugs by Integration

Bugs from Application

Distribution of Bugs related to the Test Areas Test Areas All [%] Total Testsuite 100,0 1 Basic Constructs of Language 44,0 2 Combined Constructs of Language 32,1 3 Complex Combinations 26,2 4 Inner Equivalence 28,6 5 Known Error Sources 6 Internal Structure of Code Generator 34,5 7 Specific Analyses 8 Interfaces and Integration 19,0

Agenda


Experience with tool validation Incorrect Optimization with Fused Multiply-Add / Subtract Opcodes (madd.f/msub.f) mul.f z b c Calculate a + b * c y a z add.f Description of error: C-Compiler uses Fused Multiply-Add Op-Code madd.f to calculate a +b * c in a single step  faster! y a b c madd.f Origin: Op-Code madd.f differs from documented sequence mul.f + add.f: Intermediate result z will not be rounded due to IEEE-754, but calculated with higher precision, as the calculation of the gaining factors shows:

y



a a z

z a

a z

z

Result: This is an illegal optimization, also because it is not predictable, if this transformation will be used!

Agenda


Experience with tool validation Sample problem with Subtraction and Cast (1/3)

Model

Test Results

MIL

SIL/Ref

PIL


Conversion with float to unsigned long and round to zero (neg. input -4 convertet to zero) Instead of float to signed long and round to zero?


Result is reproducible …:

No compiler failure…:

Agenda


Experience with tool validation Wrong rounding of constants with MinMax Calculation of int. maximum of three constants (-32768,-32768, 0.5) with three inputs block Code generator generates • at compile time the maximum for first part (-32768,-32768) • a runtime calculation code for the second part /* MinMax: P_Model/MinMax_3 P_Model/MinMax_3: folded operation max to constant value -32768 Variable 'Sa1_MinMax_3' replaced by 'Aux_S16' */ Aux_S16 = -32768 /* -32768. */; if (0 /* was “0.5” in Model ! */ > Aux_S16) { /* Variable 'Sa1_MinMax_3' replaced by 'Aux_S16' */ Aux_S16 = 1 /* was “0.5” in Model */; } /* TargetLink outport: P_Model/Out1__3 */ Sa1_Out1__3 = (sint32) Aux_S16;

Note: different rounding of 0.5 which may lead to issues in other context… • 0 in if-statement • 1 in assignment

Agenda


Experience with tool validation Unexpectzed behaviour with SHIFT-Operations shift operator e.g. on Uint16 has unexpected behaviour: •

if shifted more than 16 bits result is not always 0 (as might be expected and computed by reference interpreter)

Example: 46