Software Design for Safety Critical Microcontroller Applications

download Software Design for Safety Critical Microcontroller Applications

of 97

Transcript of Software Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    1/97

    Page 1Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Software Design

    forSafety Critical

    Microcontroller Applications

    by Eberhard De Wille

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    2/97

    Page 2Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Content of the Course

    - High Level Design

    - Examples of Design Problems

    - Non Functional Requirements for Software- Software Architecture

    - Interrupts, Timing and Operating Systems

    - Module Design

    - Object orientation

    - Control Flow and Data Flow

    - Include Structure

    - Data

    - Interfaces

    - Encapsulation and Structure of Modules

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    3/97

    Page 3Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Motivation:

    Some Famous Software Bugs

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    4/97

    Page 4Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    On June 26, 1988, Air France's new European A320 Airbus, delivered only two days

    previously, crashed into trees at an air show near Mulhouse in France while performing a low-

    level pass. Three passengers - a woman and two children - were killed.

    The pilot claims he was misled on the aircraft's trueheight by a bug in the software. Normally an aircraft's

    height is calculated after entering the local barometric

    pressure into its altimeter. Local ground control provides

    this to aircraft regularly so that, with each change in

    barometric pressure, the correct altitude can be displayed.The A320 has a history of occasionally selecting a

    barometric reading from memory, rather than a current

    reading, when switching from one flying mode to another. Both British Airways and Air

    France have experienced this problem with their A320s.

    Also the pilot claims that the aircraft failed to respond to its throttle. `At that point I gave the

    order to disconnect the (automatic) throttle and I'm sure that this movement put a mess in the

    computer. I push forward the throttles . . . and I had no answer.

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    5/97

    Page 5Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Several 1985-7 deaths of cancer patients were due to overdoses of radiation. The reason was abug in the Therac-25 software.

    • The operating system of the microcontroller was a bad choice.

    • Two concurrent tasks occasionally entered in a racing condition and were executed too

    often thus resulting in an overdose of radiation

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    6/97

    Page 6Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    The 1988 shooting down of the Airbus 320 by the USS Vincennes was attributed to ahuman – machine interface problem.

    • The USS Vincennes was engaged in a heavy ground battle with Iraqi gun boats.

    • Some days before the USS Stark was sunk by Iraqi gun boats.

    • The day before F14 fighters were stationed on the civil Iran airport. Their purpose

    was not known. The Iran Air Flight 655 started from this airport.• In the stress situation of the battle the civil mode 3 transponder signals were

    mistaken for mode 2 hostile military signals. (acoustic detection at this time!)

    • Warning calls and requests for identification were ignored by the A320.

    • Two missiles were fired which downed the A320 and killed 289 people

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    7/97

    Page 7Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    An Iraqi Scud missile hit Dhahran

    barracks, leaving 28 dead and 98wounded. The incoming

    missile was not detected by the Patriot

    defenses, whose clock had drifted .34

    seconds during the 4-day continuous

    siege, the error increasing withelapsed time since the system was

    turned on. This software flaw

    prevented real-time tracking. The

    specifications called for aircraft

    speeds, not Mach 6 missiles, for 14-

    hour continuous performance, not

    100. Patched software

    arrived via air one day later.

    Rounding error in Patriot Defense System leaves 28 dead and 98 wounded

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    8/97

    Page 8Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    The formula in the Patriot system to calculate the timing is:1/10 = 2 (-4) + 2 (-5) + 2 (-8) + 2 (-9) + 2 (-12) + 2 (-13) + ...

    The formula does not end and can not be represented in the 24 bit register. An error is produced in

    the range of decimal: 0.000000095

    The Patriot system was up and running for 100 hours. The deviation in the timing was therefore:

    0.000000095 * 100 * 60 * 60 * 10 = 0.34 secondsA Scud Missile flies 1676 m/s. In the deviated time the Scud was already 0.34 * 1676 = 569, 84

    meter ahead from the position where it was believed to be. After 20 hours the deviation is so big that

    the missile will be missed.

    The following table shows the growing deviation over time :

    Hours SecondsCalculated

    secondsError in seconds Deviation (meter)

    0 0 0 0 0

    1 3600 3599.9966 0.0034 7

    8 28800 28799.9725 0.0274 55

    20 72000 71999.9313 0.0687 137

    48 172800 172799.8352 0.1648 330

    72 259200 259199.7528 0.2472 494

    100 360000 359999.6667 0.3433 687

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    9/97

    Page 9Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    REMEMBER ALWAYS

    You can not test quality into softwareyou have to design it into software!

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    10/97

    Page 10Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    High Level Design

    „An Example of a bad Design“

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    11/97

    Page 11Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Task - design a microcontroller software with the following features:

    - The software shall control the current of a linear valve between 50mA – 750mA

    - The current control has to be a PI feedback controller

    - The output shall be a PWM 5-95% dc, low active, 1kHz base frequency

    - There shall be an input to preset the desired current (analog input 0- 5V)

    - There shall be a switch to start/stop the action

    - The switch input has to be de-bounced

    - Use the C164 Microcontroller for this Application

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    12/97

    Page 12Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Possible Design „By Chance“:

    void main (void){

    while(1) {

    /* main control */

    .....

    }

    }

    void get_switch (U_CHAR)

    void get_analog (void)

    void ISR(0x23) pwm (void)

    void PI_control (void)

    1 SW Module

    D_PWM_duty_cycle

    D_switch_debounced

    Global

    Variables

    D_analog_input

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    13/97

    Page 13Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Problems of a Design „By Chance“: Difficult Portability 1 (cont.)

    void get_switch(U_CHAR cm_tcu)

    {

    #define L_C_TM_DEB 30 /* de-bounce time [ms] */

    static U_SHORT l_tm_tr; /* last transition time [ms] */

    static U_CHAR l_x_1; /* previous input level */

    static U_BIT l_st_chk; /* de-bounce time check flag */

    x_sw_raw = _getbit(P2,14);

    if (x_sw_raw != l_x_1 || cm_tcu == INIT) { /* transition or init call */

    l_tm_tr = sy_tmr_1ms; /* store transition time */l_x_1 = x_sw_raw; /* store input level */

    l_st_chk = 1; /* set deb. time check flag */

    if ((cm_tcu) == INIT) x_sw = 0; /* set de-bounced level to 0 */

    }

    if (l_st_chk && sy_tmr_1ms - l_tm_tr >= L_C_TM_DEB) {

    /* de-bounce time is reached aftertransition or init call */

    x_sw = x_sw_raw; /* input level is valid */

    l_st_chk = 0; /* clear deb. time check flag */

    }

    }

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    14/97

    Page 14Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Problems of a Design „By Chance“: Difficult Portability 2 (cont.)

    void PI_control (void)

    static S_SHORT w_err_1 = 0; /* old deviation of set and current */

    static S_SHORT w_i_anteil = 0; /* variable for I portion */

    S_SHORT w_p_anteil; /* working variable for P portion */

    S_SHORT w_ss; /* signed short working variable */

    S_LONG w_sl; /* signed long working variable */

    if (i_eds1*10 > 7600){o_cr_eds1 = 7600*10; /* limit to max */}

    else{if (i_eds1*10 < 1500){o_cr_eds1 = 1500*10; /* limit to min */}

    else {o_cr_eds1= i_eds1*10 *10;}

    }

    /* calculate actual shunt current [0.1mA] using line equation

    and measured AD value */

    w_sl = ((_mul32(GRAD, i_vt_out3)) >> 8) + OFFSET;

    if (w_sl < 0) {o_cr_out3_act = 0;} /* limit current */

    else if (w_sl > 16383){o_cr_out3_act = 16383;}

    else {o_cr_out3_act = (U_SHORT)w_sl;}

    o_cr_eds3_act = o_cr_out3_act; /* for display in test system */

    o_dc_out3_1 = o_dc_out3; /* store dc for next cycle */

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    15/97

    Page 15Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Problems of a Design „By Chance“: Difficult Portability 3

    /* calculate current deviation [0.1mA] */

    w_ss = (S_SHORT)(o_cr_out3) - (S_SHORT)(o_cr_out3_act);

    w_p_anteil = _mul32(w_fct_p_out3, w_ss) >> 16; /* P calculation */

    w_i_anteil += _mul32(w_fct_i_out3, w_ss + w_err_1) >> 17; /* calc. I */

    w_err_1 = w_ss;

    if (w_i_anteil < 0) {w_i_anteil = 0;} /* limit I portion */

    else if (w_i_anteil > 20000) {w_i_anteil = 20000;}w_ss = w_i_anteil + w_p_anteil; /* duty cycle = P- + I-portion */

    if (w_ss < 0) {o_dc_out3 = 0;} /* limit/correct duty cycle */

    else {o_dc_out3 = _mulu32(w_cor, (U_SHORT)(w_ss)) >> 10;}

    /* limit duty cycle */

    if (o_cr_out3_act < 500){ if (o_dc_out3 > 7500){o_dc_out3 = 7500;}}else {if (o_dc_out3 > 9500){o_dc_out3 = 9500;}}

    drv_pwm3_set(o_dc_out3); /* output duty cycle */

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    16/97

    Page 16Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Problems of a Design „By Chance“: Bad Maintainability

    /* calculate current deviation [0.1mA] */

    w_ss = (S_SHORT)(o_cr_out3) - (S_SHORT)(o_cr_out3_act);

    w_p_anteil = _mul32(w_fct_p_out3, w_ss) >> 16; /* P calculation */

    w_i_anteil += _mul32(w_fct_i_out3, w_ss + w_err_1) >> 17; /* calc. I */

    w_err_1 = w_ss;

    if (w_i_anteil < 0) {w_i_anteil = 0;} /* limit I portion */

    else if (w_i_anteil > 20000) {w_i_anteil = 20000;}w_ss = w_i_anteil + w_p_anteil; /* duty cycle = P- + I-portion */

    if (w_ss < 0) {o_dc_out3 = 0;} /* limit/correct duty cycle */

    else {o_dc_out3 = _mulu32(w_cor, (U_SHORT)(w_ss)) >> 10;}

    /* limit duty cycle */

    if (o_cr_out3_act < 500){ if (o_dc_out3 > 7500){o_dc_out3 = 7500;}}else {if (o_dc_out3 > 9500){o_dc_out3 = 9500;}}

    drv_pwm3_set(); /* output duty cycle */

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    17/97

    Page 17Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Problems of a Design „By Chance“: Unclear Interfaces 1 (cont.)

    void PI_control (void)

    static S_SHORT w_err_1 = 0; /* old deviation of set and current */

    static S_SHORT w_i_anteil = 0; /* variable for I portion */

    S_SHORT w_p_anteil; /* working variable for P portion */

    S_SHORT w_ss; /* signed short working variable */

    S_LONG w_sl; /* signed long working variable */

    if (i_eds1*10 > 7600){o_cr_eds1 = 7600*10; /* limit to max */}

    else{if (i_eds1*10 < 1500){o_cr_eds1 = 1500*10; /* limit to min */}

    else {o_cr_eds1= i_eds1*10 *10;}

    }

    /* calculate actual shunt current [0.1mA] using line equation

    and measured AD value */

    w_sl = ((_mul32(GRAD, i_vt_out3)) >> 8) + OFFSET;

    if (w_sl < 0) {o_cr_out3_act = 0;} /* limit current */

    else if (w_sl > 16383){o_cr_out3_act = 16383;}

    else {o_cr_out3_act = (U_SHORT)w_sl;}

    o_cr_eds3_act = o_cr_out3_act; /* for display in test system */

    o_dc_out3_1 = o_dc_out3; /* store dc for next cycle */

    Language interface not used!

    Input interface scattered over the code

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    18/97

    Page 18Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Problems of a Design „By Chance“: Unclear Interfaces 2

    /* calculate current deviation [0.1mA] */

    w_ss = (S_SHORT)(o_cr_out3) - (S_SHORT)(o_cr_out3_act);

    w_p_anteil = _mul32(w_fct_p_out3, w_ss) >> 16; /* P calculation */

    w_i_anteil += _mul32(w_fct_i_out3, w_ss + w_err_1) >> 17; /* calc. I */

    w_err_1 = w_ss;

    if (w_i_anteil < 0) {w_i_anteil = 0;} /* limit I portion */

    else if (w_i_anteil > 20000) {w_i_anteil = 20000;}w_ss = w_i_anteil + w_p_anteil; /* duty cycle = P- + I-portion */

    if (w_ss < 0) {o_dc_out3 = 0;} /* limit/correct duty cycle */

    else {o_dc_out3 = _mulu32(w_cor, (U_SHORT)(w_ss)) >> 10;}

    /* limit duty cycle */

    if (o_cr_out3_act < 500){ if (o_dc_out3 > 7500){o_dc_out3 = 7500;}}else {if (o_dc_out3 > 9500){o_dc_out3 = 9500;}}

    drv_pwm3_set(); /* output duty cycle */

    Input interface scattered over the code

    Output interface scattered over the code

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    19/97

    Page 19Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Problems of a Design „By Chance“: Possible Cross Influences – Global Variables

    void PI_control (void)

    static S_SHORT w_err_1 = 0; /* old deviation of set and current */

    static S_SHORT w_i_anteil = 0; /* variable for I portion */

    S_SHORT w_p_anteil; /* working variable for P portion */

    S_SHORT w_ss; /* signed short working variable */

    S_LONG w_sl; /* signed long working variable */

    if (i_edsl*10 > 7600){o_cr_eds1 = 7600*10; /* limit to max */}

    else{if (i_eds1*10 < 1500){o_cr_eds1 = 1500*10; /* limit to min */}

    else {o_cr_eds1= i_eds1*10 *10;}

    }

    /* calculate actual shunt current [0.1mA] using line equation

    and measured AD value */

    w_sl = ((_mul32(GRAD, i_vt_out3)) >> 8) + OFFSET;

    if (w_sl < 0) {o_cr_out3_act = 0;} /* limit current */

    else if (w_sl > 16383){o_cr_out3_act = 16383;}

    else {o_cr_out3_act = (U_SHORT)w_sl;}

    o_cr_eds3_act = o_cr_out3_act; /* for display in test system */

    o_dc_out3_1 = o_dc_out3; /* store dc for next cycle */

    Do you see the error?

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    20/97

    Page 20Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    High Level Design

    „Requirements for a good Design“

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    21/97

    Page 21Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    A Better Design is required with the following Features:

    • Correctness and Safety

    • Complete and correct requirements

    • Dual path principle has to be implemented (if necessary)

    • Implemented safety measures e.g. checksums for memory and

    communication protocols

    • Fall back to a safe condition in case of an detected error

    • Use a safe subset of standard – C (e.g. data types)

    • Free from malfunction (test coverage)• The use of standard C-libraries and other third party software

    components has to be avoided (certification and testing problem!)

    • Robustness• Correct behavior in case of unexpected inputs or events

    • Enough resources available for worst case situations

    • Operating System design must guarantee the „first things first“

    principle

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    22/97

    Page 22Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    A Better Design is required with the following Features:

    • Robustness (cont.)

    • Additions have to be possible without destabilizing the existing SW

    • Changes in one code portion must not influence other portions

    • Portability

    • Switches to other HW platforms have to be possible without code

    changes in the application part (e.g. for simulation and uC)• Use a subset of standard – C as far as possible. Compiler / platform

    specific features have to be located in specific libraries or a HW

    abstraction layer

    • Platform specific data type sizes have to be considered

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    23/97

    Page 23Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    A Better Design is required with the following Features:

    • Testability

    • Clear and simple interfaces (number of values, basic data types)

    • Standard C as far as possible• No redefinitions (nested definitions)

    • No cross influences (e.g. no global variables)

    • Test stubs, test interfaces, etc. should be already part of the design

    • Maintainability

    • Header structure has to be simple (no dependencies)

    • Module size and breakdown has to be carefully considered

    • Comments in the code have to make sense

    • Templates have to be used for modules and headers• Defines have to be used instead of fixed values in the code

    • Adhere to rules of testability

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    24/97

    Page 24Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    A Better Design is required with the following Features:

    • Reusability

    • Adhere to the rules of testability and maintainability

    • Scalability has to be supported• The documentation level should be very good

    • The test coverage should be very good (maturity of Software)

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    25/97

    Page 25Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    High Level Design

    „Features of a good Design“

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    26/97

    Page 26Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Better Design: „Defined Architecture“ - Overview

    HW Abstraction Layer

    FunctionalLibrary

    C

    Library

    Frame Work

    Function

    Block 2

     O p e r  a t  i  n g S  y s  t   e m

    Microcontroller Hardware

     O S  O S  O S  O S A b  s  t  r 

     a c  t  i   onL  a y er 

    L  a y er 

    L  a y er 

    L  a y er 

    Function

    Block 1

    Function

    Block 3

    Physical Layer

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    27/97

    Page 27Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Better Design: „Defined Architecture“ – Aim for the Application SW

    Functional

    Library

    CLibrary

    Frame Work

    Function

    Block 2

    Function

    Block 1

    Function

    Block 2

    Physical Layer

    - Robust design without cross influences

    - Portability therefore no dependencies to HW or OS

    - Maintainability therefore clear structures and clear interfaces

    - High quality and stability of the application

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    28/97

    Page 28Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Better Design: „Defined Architecture“ – HW Abstraction Layer

    Purpose - Adaptation to the Microcontroller Hardware

    U_SHORT us_GetOnOffSwitchRaw(void)

    {

    U_SHORT x_sw_raw;

    x_sw_raw = _getbit(P2,14);

    return(x_sw_raw);

    }

    HW Abstraction LayerHW Abstraction LayerHW Abstraction LayerHW Abstraction Layer

    Adaptation to the Implementation

    Adaptation to the uC Platform

    Standard Interface to the Physical Layer

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    29/97

    Page 29Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Better Design: „Defined Architecture“ – OS Abstraction Layer

    Purpose - Adaptation to the Operating System

    void v_StartEventTask(U_SHORT us_Event)

    {

    switch (us_Event)

    {

    case ERROR: { T_TskStart(0);

    break; }

    case POWER_DOWN: { T_TskStart(1);

    break;}

    }

    }

    OS Abstraction LayerOS Abstraction LayerOS Abstraction LayerOS Abstraction Layer Adaptation Adaptation Adaptation Adaptation

    ToToToTo

    FrameFrameFrameFrame

     Work Work Work Work

     Adaptation Adaptation Adaptation Adaptation

    ToToToTo

    OperatingOperatingOperatingOperating

    SystemSystemSystemSystem

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    30/97

    Page 30Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Better Design: „Defined Architecture“ – Physical Layer

    Purpose – Presentation of Normalized Physical Values to the Application

    U_SHORT us_GetOnOffSwitch(U_SHORT cm_tcu, U_SHORT sy_tmr_1ms)

    {

    static U_SHORT l_tm_tr, l_x_1, l_st_chk, x_sw, x_sw_raw;

    x_sw_raw = us_GetOnOffSwitchRaw();if (x_sw_raw != l_x_1 || cm_tcu == INIT) { /* transition or init call */

    l_tm_tr = sy_tmr_1ms; l_x_1 = x_sw_raw; l_st_chk = 1;

    if ((cm_tcu) == INIT) x_sw = 0; l_tm_tr = 0; l_x_1 = 0; l_st_chk = 0;

    }

    if (l_st_chk && sy_tmr_1ms - l_tm_tr >= L_C_TM_DEB) {

    x_sw = x_sw_raw; l_st_chk = 0;}

    return(x_sw);

    }

    Physical LayerPhysical LayerPhysical LayerPhysical Layer

    Interface to HW Abstraction Layer

    Normalized Interface to Application

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    31/97

    Page 31Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Better Design: „Defined Architecture“ – Frame Work

    Purpose – Perform the Control Flow of the Application

     VOID v_MainFunction(VOID)

    {

    U_SHORT us_Switch, us_AnalogValue, l_st_chk, x_sw, x_sw_raw;

    us_Switch = us_GetOnOffSwitch();

    if (us_Switch == ON){ /* transition or init call */

    us_AnalogValue = us_GetAnalogSetting();

    v_PerfomCurrentControl(us_AnalogValue);

    }

    else {

    v_PerfomCurrentControl(DEFAULT_CURRENT);}

    }

    Frame WorkFrame WorkFrame WorkFrame Work

    Interface to the OS Abstraction Layer

    Interface to the Application

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    32/97

    Page 32Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Better Design: „Defined Architecture“ – Functional - Library

    Purpose – Provide Tested Standard Solutions for Repeated Tasks

    Specific Solutions which are application related

    Functional

    Library

    Either simple C-functions (volatile data)

    OR object instances for functions which need

    static data

    Advantage: Generally valid solutions

    Advantage: Documentation and test coverage is

    better than for project specific code

    Advantage: Reuse saves time and effort

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    33/97

    Page 33Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Better Design: „Defined Architecture“ – C - Library

    Purpose – Provide Tested Standard Solutions for Repeated Tasks

    C

    Library

    Substitute the Standard C - Libraries

    Only simple C-functions (volatile data)

    Optimization and Adaptation to Microcontrollers

    Advantage: Generally valid solutions

    Advantage: Documentation and test coverage is

    better than for project specific code

    Advantage: Reuse saves time and effort

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    34/97

    Page 34Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Better Design: „Defined Architecture“ – Benefits of Libraries

    Function Block 1

    C-Library

    Function Block 2 1. Generic functionswritten only once

    2. Possibility to use all

    or only some of the

    code in the libraryFunction Block 3

    Absolute

    Shifting

    Division

    Limitation

    RefLine

    Absolute

    ShiftingLimitation

    Absolute

    LimitationDivision

    Shifting

    DivisionRefLine

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    35/97

    Page 35Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Better Design: „Defined Architecture“ – Benefits of Libraries

    TEST

    3. Once the library

    tested, only the

    other SW functions

    need to be tested

    4. SW changes do not

    imply retesting the

    library functions

    used

    C-Library

    Absolute

    Shifting

    Division

    LimitationRefLine

    Function Block 1

    Function Block 2

    Function Block 3

    Specific

    Algorithms

    Abs

    ShiftLimit

    Specific

    Algorithms

    Abs

    LimitDiv

    SpecificAlgorithms

    Shift

    DivRefLine

    SW D i f S f C i i l Mi ll A li i

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    36/97

    Page 36Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Better Design: „Defined Architecture“ – Benefits of Libraries

    uC C164

    5. Library accommodates

    different versions of

    same function

    depending on uC used

    6. Algorithms can begenerally coded and

    does not need to

    change because of

    changing the uC

    C-Library

    Absolute

    Shifting

    DivisionLimitation

    RefLine

    Absolute

    Shifting

    DivisionLimitation

    RefLine

    uC TMS470Absolute

    ShiftingDivision

    Limitation

    RefLine

    uC ST7AbsoluteShifting

    Division

    Limitation

    RefLine

    SW D i f S f t C iti l Mi t ll A li ti

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    37/97

    Page 37Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    High Level Design„Interrupts, Timing and

    Operating Systems“

    SW D i f S f t C iti l Mi t ll A li ti

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    38/97

    Page 38Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Non - Optimized Architecture of Pseudo Microcontrollers:

    ASC Unit

    uC IR Level

    Timer / 

    CAPCOM Unit

    uC IR Level

    uC IR Level

    General Purpose CPU

    SSC Unit

    ADC Unit

    ControlRegisters

    ControlRegisters

    ControlRegisters

    Control

    Registers

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    39/97

    Page 39Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Non - Optimized Architecture of Pseudo Microcontrollers:Pseudo Microcontroller: A standard CPU core is used (e.g. ARM7 or MPC) and

    peripheral devices are attached via a bus.

    • Inexpensive due to high volumes but inefficient and hard to program

    • Insufficient interrupt levels (leads to restrictions in the operating system)

    • No direct control register access (delays and restrictions)

    • Slow (delayed) access to peripheral devices (e.g. the setting of a port pin in the

    HET of the TMS470 takes approximately 1.4us)

    • Special peripheral activities have to be programmed into the peripheral

    device. This leads to constraints of usage and complicates programming.

    • Mapping of special peripheral features to an interrupt are impossible. Only

    the complete unit can be assigned to an interrupt.

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    40/97

    Page 40Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Optimized uC Architecture:

    uC IR Level

    Timer / CAPCOM Unit

    Dedicated uC

    SSC Unit

    ADC UnitControl

    Registers

    uC IR Level

    uC IR Level

    uC IR Level

    uC IR Level

    uC IR Level

    uC IR Level

    uC IR Level

    uC IR Level

    uC IR LeveluC IR Level

    uC IR Level

    uC IR Level

    uC IR Level

    ControlRegisters

    ControlRegisters

    ControlRegisters ASC Unit

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    41/97

    Page 41Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Optimized Microcontroller Architecture:Real Microcontroller: A dedicated CPU core with specially designed peripheral

    features which are „on chip“ and attached in the best possible manner.

    • More expensive due to lower volumes but very efficient in application

    • Sufficient interrupt levels to cover all needs

    • Direct and optimized control register access special features like PEC (kind

    of DMA) are supported

    • Immediate access to peripheral devices (e.g. the setting of a port pin in the

    C164 takes approximately 50ns)

    • Mapping of special peripheral features to an interrupt are possible. Special

    I/O handling is therefore possible.

    • Less risk to ship an instable application (because of optimized programming

    possibilities)!

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    42/97

    Page 42Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Optimized uC Architecture: Example of IR assignments (1)

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    43/97

    Page 43Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Optimized uC Architecture: Example of IR assignments (2)

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    44/97

    Page 44Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Operating Systems: Behavior of a preemptive vs. a cooperative OS

    1 ms

    delay

    Cooperative Operating System

    Preemptive Operating System

    Task 

    interruption

    2ms task 

    4ms task 

    2ms task 

    4ms task 

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    45/97

    Page 45Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

    Operating Systems: Features of a Preemptive Operating System

    • Exact task start times thus suitable for sampling and feedback control

    purposes

    • Provides a stable basis for highest performance

    • Allows slow „background tasks“ and optimized CPU resource usage

    • Needs sufficient IR levels on the microcontroller

    • Needs sufficient stack resources

    • Needs attention concerning data interference due to preemption (however,

    this is no problem if OOP is applied)

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    46/97

    Page 46Copyright © 2010 Eberhard De Wille

    SW es g o Sa ety C t ca c oco t o e pp cat o s

    Operating Systems: Features of a Cooperative Operating System

    • Task start times are unstable thus control and sampling is usually done

    in timer interrupts rather than proper OS tasks

    • Stable basis only with higher constraints concerning CPU load and higherattention in the application itself 

    • Background tasks and optimized CPU resource usage not possible

    • No special requirements concerning IR levels on the microcontroller

    • No special requirements concerning stack resources

    • No attention concerning data interference BUT concerning task overflows

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    47/97

    Page 47Copyright © 2010 Eberhard De Wille

    g y pp

    Operating Systems: Example of an OS Design for a „Brake by Wire“ System

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    48/97

    Page 48Copyright © 2010 Eberhard De Wille

    g y pp

    Operating Systems: Example of an OS Design for a „Brake by Wire“ System

    200µs Task

    This task has the highest priority over all other tasks. It is exclusively used for the

    motor current control. This control runs for approximately 50 micro seconds and thus

    makes up about 25% of the total CPU load of the system. The task is triggered

    (called) by the T13 timer overflow interrupt. The timer is then reloaded with the sametime value to generate the next interrupt in 200 micro seconds.

    T_tsk_2ms

    The 2ms task is a periodic task which is called every 2ms by the task scheduler. It is

    one of the most important tasks (besides the 4ms task) of the system. Mainly itcontains the wheel speed calculation and the calls of the functional software which

    perform the motor speed- and force control.

    T_tsk_4ms

    The 4ms task is called periodically every 4ms and is the second important task of the

    system. It contains some function calls of the functional software e.g. for motor

    speed- and force control as well as the input functions for the pedal values and the

    multiplexed data. Further the CCP control task is called for application of data and the

    external watchdog is triggered.

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    49/97

    Page 49Copyright © 2010 Eberhard De Wille

    g y pp

    Operating Systems: Example of an OS Design for a „Brake by Wire“ System

    T_tsk_8ms and T_tsk_16ms

    The 8ms task and 16ms task are periodic tasks which are cooperative, i.e. they can not

    interrupt each other. Every 16ms both tasks have to be started. The 8ms task is runfirst and immediately after it is finished the 16ms task is started.

    The 8ms task contains the detection of the CAN boot loader, the power down

    mechanism and the de-bouncing of digital as well as some analog input signals.

    The 16ms task is used for reading the temperatures of the SCU, the force sensor and

    the motor. Further some error filtering and the measuring the boards supply voltage is

    performed here.

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    50/97

    Page 50Copyright © 2010 Eberhard De Wille

    Operating Systems: Example of an OS Design for a „Brake by Wire“ System

    T_tsk_128ms

    This task is called every 128ms and contains only the initialization and supervision of

    the TTP controller. In case the communication system does not work correctly, e.g.due to damaged bus lines, the TTP controller is reset.

    T_tsk_ini

    This task is called once after reset before the task scheduler starts to control the other

    tasks. The initialization of the hardware, SFRs and the software is performed here.

    T_Idle

    This task is active every time there is no other CPU activity. Thus it constitutes a

    background task. It is used for the stack supervision and the permanent ROM check.

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    51/97

    Page 51Copyright © 2010 Eberhard De Wille

    Module Design

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    52/97

    Page 52Copyright © 2010 Eberhard De Wille

    Module Design

    „Object Orientation“

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    53/97

    Page 53Copyright © 2010 Eberhard De Wille

    Better Design: „Object Orientation“ – Some Quotes

    Coad: "Encapsulation (Information Hiding). A principle, used when

    developing an overall program structure, that each component of a

    program should encapsulate or hide a single design decision... The

    interface to each module is defined in such a way as to reveal as little as

    possible about its inner workings"

    Cox: "An object is anything with a crisply defined boundary"

    Smith and Tockey: "An object represents an individual, identifiable item,unit, or entity, either real or abstract, with a well-defined role in the

    problem domain."

    Booch: "Encapsulation is the process of hiding all of the details of anobject that do not contribute to its essential characteristics."

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    54/97

    Page 54Copyright © 2010 Eberhard De Wille

    Better Design: „Object Orientation“ – A simple Example

    Interfaces of the Object:

    Seat

    Back support

    Arm rest

    Adjustment lever

    5 Wheels

    Hidden Properties of the Object:

    Mounting screws, e.g. of the arm restAdjusting mechanism

    Suspension

    Seat filling, etc. etc.

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    55/97

    Page 55Copyright © 2010 Eberhard De Wille

    Better Design: „Object Orientation“ – A rough Conclusion / Definition

    Boundaries (interfaces) have to be small and narrow. If they are not, the

    definition of the object (s) may not be correct.

    The split up of program units (called modules in most languages) has to

    be done according to real life objects rather than being process driven.

    If real life objects are not detectable abstract objects may be taken.

    Example: A sensor is a real life object, the related filter could be more anabstract object.

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    56/97

    Page 56Copyright © 2010 Eberhard De Wille

    Better Design: „Object Orientation“ – Another Example

    Sensor Raw DataAcquisition Object

    Sensor FilteringObject

    Sensor DiagnosticsObject

    Sensor Object

    Sensor Raw Data

    Sensor Raw Data

    Sensor FilteredData and Diagnostic Information

    Sensor Filtered Data Sensor Diagnostic Information

    Sensor Filtered Data Sensor Diagnostic Information

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    57/97

    Page 57Copyright © 2010 Eberhard De Wille

    Better Design: „Object Orientation“ – A rough Conclusion / Definition

    Contrary to a process oriented SW design an OO design has to include

    data and code inside the object.

    Information hiding is mandatory. There has to be a defined interface to

    the outside world and everything else has to be hidden inside the object,

    invisible for others.

    Do not mistake OOP with the use of certain programming languages and

    concepts such as Classes, Inheritance, etc.

    Errors which can be made e.g. in C++: Definition of objects is not good(interfaces too big), making too much "public", friend class definitions

    (loss of information hiding).

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    58/97

    Page 58Copyright © 2010 Eberhard De Wille

    Module Design

    „Control Flow and Data Flow“

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    59/97

    Page 59Copyright © 2010 Eberhard De Wille

    Module Design: „Control Flow and Data Flow“ – C.F. driven approach

    OS function(1ms)

    AlgorithmMain Function

    AlgorithmTerm1

    AlgorithmTerm 2

    AlgorithmWeightingFunction

    X-Sensor

    Filtering

    Get X-SensorRaw Data

    X-Sensorabs calculation

    X-rawvalue

    X-filteredvalue

    X-filteredabs value

    Fire flagsTerm data

    Black arrows are

    control flow

    Red arrows are

    data flow

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    60/97

    Page 60Copyright © 2010 Eberhard De Wille

    Module Design: „Control Flow and Data Flow“ – C.F. driven Approach

    • Global variables are part of this design. Thus all involved problems like cross

    influences, increased RAM consumption and slower speed are present

    • Data flow is hard to comprehend and can easily change with a code change

    • Interfaces in the functions are scattered over the function

    • No clear components and objects. Thus decreased reusability

    • Testability is bad (especially data flow checks, component testing and

    interface testing

    • Maintainability is bad because small changes may have big unwanted effects

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    61/97

    Page 61Copyright © 2010 Eberhard De Wille

    Module Design: „Control Flow

    and Data Flow“ – D.F. driven Approach

    TermEvaluation

    Term 1

    Airbag firedecision

    Term 2

    Term 3

    Term 4

    Get RawSensor Value

    Get RawSensor Value

    Get RawSensor Value

    Calculate FilteredSensor Value

    Get RawSensor Value

    Calculate FilteredSensor Value

    Calculate FilteredSensor Value

    Calculate FilteredSensor Value

    Note: the colors denotethat the functions belongto different objects

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    62/97

    Page 62Copyright © 2010 Eberhard De Wille

    Module Design: „Control Flow

    and Data Flow“

    Optimized Version of 

    D.F. driven Approach

    Term

    Evaluation

    Term 1

    Airbag firedecision

    Term 2

    Term 3

    Term 4

    Get FilteredSensor Value

    Get FilteredSensor Value

    Get FilteredSensor Value

    Get FilteredSensor Value

    DataPre-processing

    Calculate FilteredSensor Value

    Get Raw

    Sensor Value

    Note: the colors denotethat the functions belongto different objects

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    63/97

    Page 63Copyright © 2010 Eberhard De Wille

    Module Design: „Control Flow and Data Flow“ – D.F. driven - Example

    FireMatrix

    Function

    AlgorithmMain Function

    Fireflags

    AlgorithmTerm1

    AlgorithmTerm 2

    Firedecision Algorithm

    WeightingFunction

    term 1

    data term 2data

    X-Sensor Filtering

    X-SensorRaw Data

    Filtered sensor value and

    Abs of filtered value

    Sensor filteredvalue

    Sensor raw value

    X-Sensorabs calculation

    X-SensorObject

    Filtered sensor value andAbs of filtered value

    Sensor filtered abs value

    X-rawvalue

    X-filteredvalue

    X-filteredabs value

    Fire flags

    Term 1 data Term 2 data

    Firedescision

    Black arrows are

    control flow

    Red arrows are

    data flow

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    64/97

    Page 64Copyright © 2010 Eberhard De Wille

    Module Design: „Control Flow and Data Flow“ – D.F. driven - Example

    • Best possible encapuslation and object orientation without cross influences

    among the code parts

    • Data flow is to a large extent synchronous with the control flow and therefore

    easy to comprehend and to test

    • Interfaces are clear and can be designed simple

    • Maximum reusability and easy integration because of object oriented

    and encapsulated modules

    •Easy testability because each object can be tested separately and has clear

    interfaces and no cross influences

    • Easy maintainability due to small scope of changes and least possible

    cross influences

    • Less RAM and runtime consumption because of avoiding global variables

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    65/97

    Page 65Copyright © 2010 Eberhard De Wille

    Module Design: „Control Flow and Data Flow“

    Conclusions:

    • Consequently the use of global variables or unmotivated use of module wide

    static variables has to be avoided.

    • The adherence to an object oriented design will support the idea of a

    synchronized control and data flow.

    • The module design has to be done carefully. Interfaces have to be narrow

    (e.g. basic data types instead of arrays and structures) and small (as less

    interfaces (e.g. get-functions) as possible.

    • The use of the technical interface of the C programming language, with itspass and return parameters is a prerequisite to achieve synchronization of the

    control and data flow.

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    66/97

    Page 66Copyright © 2010 Eberhard De Wille

    Module Design

    „Include Structure“

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    67/97

    Page 67Copyright © 2010 Eberhard De Wille

    Module Design: „Include structure“ – Bad Example

    SW Design for Safety Critical Microcontroller Applications

    M d l D i I l d “ G d E l

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    68/97

    Page 68Copyright © 2010 Eberhard De Wille

    Module Design: „Include structure“ – Good Example

    #ifdef HOME

    #undef PRIVATE

    #undef HOME

    #define PUBLIC

    #define PROTECTED/*------------------------------------------*/

    /* General Includes */

    /*------------------------------------------*/

    #include "GLB_Datatypes.h"

    #include "AAL_gMacros.h"

    #include "AAL_gCLib.h"/*------------------------------------------*/

    /* Specific Includes */

    /*------------------------------------------*/

    #include "AAL_gProjTypes.h"

    #include "AAL_gSwIFaceIn.h"#include "AAL_gOtherModule.h"

    #define PRIVATE

    #endif

    Global data types

    (basic types for all

    modules)

    Macros (defines) for allmodules

    Header of own library

    functions

    Project specific data types

    Interfaces of other SW

    layers

    Interfaces of other SW

    Modules (same SW

    component)

    SW Design for Safety Critical Microcontroller Applications

    M d l D i I l d t t “ E l f l b l d t t

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    69/97

    Page 69Copyright © 2010 Eberhard De Wille

    Module Design: „Include structure“ –Example of global data types

    #define T_VOID void // void

    typedef unsigned char T_UCHAR; // 8 bit unsigned

    typedef signed char T_SCHAR; // 8 bit signed

    typedef unsigned short int T_USHORT; // 16 bit unsignedtypedef short T_SSHORT; // 16 bit signed

    typedef unsigned long int T_ULONG; // 32 bit unsigned

    typedef long int T_SLONG; // 32 bit signed

    • Definition of own basic data types allows adaptation to other CPU platforms

    • Definition of own basic data types allows own simple types based on basic types

    • Note that PC-Lint and the Lint-MISRA checker NEED redefinitions of the

    basic datatypes. If this is not done Lint only come up with a warning concerning

    this fact and is not able to find other errors.

    SW Design for Safety Critical Microcontroller Applications

    M d l D i I l d t t “ E l f i l d fil

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    70/97

    Page 70Copyright © 2010 Eberhard De Wille

    Module Design: „Include structure“ –Example of a macro include file

    #define TRUE 1

    #define FALSE 0

    #define NULL 0

    #define SET |=

    #define RESET &=~

    #define TEST &

    /* inline definitions depending on uC */

    #undef INLINE // it will be set in any case below#if CPU == TMS470

    #define INLINE __inline

    #endif //if CPU == TMS470

    #if CPU == C164

    #define INLINE _inline

    #endif //if CPU == C164

    SW Design for Safety Critical Microcontroller Applications

    Module Design: Include structure“ Example of a project data type file

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    71/97

    Page 71Copyright © 2010 Eberhard De Wille

    Module Design: „Include structure“ –Example of a project data type file

    #define AF_ub_MAX_REAR_THR 4 // max. thresh. for rear crash

    #define AF_ub_FILTER_16_8 (T_UBYTE) 8 // Shift from 16 bit to 8 bit

    #define AF_ub_HIGHBYTE (T_UBYTE) 8 // Shift from 16 bit to 8 bit

    /*------------------------------------------*/

    /* T Y P E - D e c l a r a t i o n s *//*------------------------------------------*/

    typedef struct S_INTAREA

    {

    T_UBYTE ub_Term1;

    T_UBYTE ub_Term2;

    T_UBYTE ub_ff;T_UBYTE ub_stop;

    } S_INTAREA;

    typedef struct S_FUZZYSET

    {

    T_UBYTE p1;

    T_UBYTE p2;

    T_UBYTE p3;

    T_UBYTE p4;

    } S_FUZZYSET;

    SW Design for Safety Critical Microcontroller Applications

    Module Design: Include structure“ Conclusion

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    72/97

    Page 72Copyright © 2010 Eberhard De Wille

    Module Design: „Include structure – Conclusion

    • Use a defined structure which is well thought about

    • Keep it always clean and according to the definition

    • Make it simple and logical with clear allocations of items

    • Use only single level includes

    • Avoid nesting, cross includes and dependencies

    • Do not let includes grow wild. Plan it and design it!

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    73/97

    Page 73Copyright © 2010 Eberhard De Wille

    Module Design

    „Encapsulation and General Structure“

    SW Design for Safety Critical Microcontroller Applications

    Module Design: Design Example“ – ADTs

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    74/97

    Page 74Copyright © 2010 Eberhard De Wille

    Module Design: „Design Example – ADTs

    • ADT stands for Abstract Data Types. A Object Oriented Design Methodfor the C-language. Described in the Microsoft Press 1980

    • Only one file which acts as header or as source code moduleUsage:

    • Get- and Set-functions as interface to other software

    • Private sub-functions only used inside the module itself 

    #define HEADER

    #include “ADTxxx.c"

    #undef HEADER

    • Separation of „Exported“ (Public) and „Private“ defines, data and functions

    • Since the header and source are combined in one file there will never be a

    discrepancy between badly maintained files.

    SW Design for Safety Critical Microcontroller Applications

    Module Design: „Design Example“ – ADTs

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    75/97

    Page 75Copyright © 2010 Eberhard De Wille

    Module Design: „Design Example ADTs

    SW Design for Safety Critical Microcontroller Applications

    Module Design: „Design Example“ – ADTs

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    76/97

    Page 76Copyright © 2010 Eberhard De Wille

    Module Design: „Design Example ADTs

    SW Design for Safety Critical Microcontroller Applications

    Module Design: „Design Example“ – ADTs

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    77/97

    Page 77Copyright © 2010 Eberhard De Wille

    g „ g p

    SW Design for Safety Critical Microcontroller Applications

    Module Design: „Design Example“ – ADTs

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    78/97

    Page 78Copyright © 2010 Eberhard De Wille

    g „ g p

    SW Design for Safety Critical Microcontroller Applications

    Module Design: „Design Example“ – ADTs

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    79/97

    Page 79Copyright © 2010 Eberhard De Wille

    g g p

    SW Design for Safety Critical Microcontroller Applications

    Module Design: „Design Example“ – ADTs

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    80/97

    Page 80Copyright © 2010 Eberhard De Wille

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    81/97

    Page 81Copyright © 2010 Eberhard De Wille

    Module Design

    „Data“

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    82/97

    SW Design for Safety Critical Microcontroller Applications

    Module Design: „Data“ – Principles of Data to use

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    83/97

    Page 83Copyright © 2010 Eberhard De Wille

     ModuleA.c

     ModuleA.h

    • No global variables to other SW parts

    • Use local variables inside the functions as far as possible

    #define HOME

    #include “ModuleA.h"

    #undef HOME

    #ifdef PUBLIC// No global variables to other software

    #endif //PUBLIC

    #ifdef PROTECTED

    // No global variables to other software

    #endif //PROTECTED

    #define PRIVATE

    static T_UWORD Variable1;

    static T_UBYTE Variable2;

    #endif //PRIVATE

    • If needed for validity over multiple calling cycles use static variables

    inside the functions as far as possible (see init example on the next page)• If needed for cross function validity use static variables with module wide

    scope

    SW Design for Safety Critical Microcontroller Applications

    Module Design: „Data“ – Design Pattern for Static Variable Initialization

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    84/97

    Page 84Copyright © 2010 Eberhard De Wille

     ModuleA.c  ModuleA.h

    #define HOME

    #include “ModuleA.h"

    #undef HOME

    T_VOID Init_ModuleA (T_VOID)

    {

    function2(INIT);

    Variable1 = 0;

    Variable2 = 0;

    }

    void function2 (T_UWORD Mode)

    {

    static T_UWORD Variable4;

    T_UWORD Variable5;

    if (Mode == INIT) {Variable4 = 0;}

    else{

    // normal code for operation

    }

    }

    #ifdef PUBLIC

    // No global variables to other software

    #endif //PUBLIC

    #ifdef PROTECTED

    // No global variables to other software

    #endif //PROTECTED

    #define PRIVATE

    #define INIT 0

    #define RUN 1static T_UWORD Variable1;

    static T_UBYTE Variable2;

    #endif //PRIVATE

    SW Design for Safety Critical Microcontroller Applications

    Module Design: „Data“ – Access to the Data in a Module via Get-functions

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    85/97

    Page 85Copyright © 2010 Eberhard De Wille

    and Set-functions

     ModuleB.c

    #define HOME

    #include “ModuleB.h"

    #undef HOME

    static T_UWORD Variable1;

    T_VOID Init_ModuleA (T_VOID)

    {

    Variable1 = 0;

    }

    T_VOID function2 (T_VOID){

    T_UWORD Variable5;

    //some code

    Variable1 = 12345; // some result

    }

    T_UWORD Get_Variable1 (T_VOID){ return(Variable1); }

    T_UWORD Set_Variable1 (T_UWORD value)

    { Variable1 = value; }

     ModuleA.c

    #define HOME

    #include “ModuleA.h"

    #undef HOME

    T_VOID function2 (T_VOID)

    {

    T_UWORD Variable5;

    //some code

    Variable123 = Get_Variable1();

    }

    T_VOID function2 (T_VOID)

    {

    T_UWORD Variable5;

    //some code

    Set_Variable1(Variable5);

    }

    SW Design for Safety Critical Microcontroller Applications

    Module Design: „Data“ - The resource problem with global/static variables

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    86/97

    Page 86Copyright © 2010 Eberhard De Wille

    void CLASS_NAME AR_vFiltY_Signal()

    {

    // IIR filter (1/4)

    T_SWORD sw_temp;

    T_SWORD sw_temp1;

    sw_temp = GMrs_AccY;

    sw_temp = sw_temp / 4;

    sw_temp1 = ARrsw_ay_iir;sw_temp1 = sw_temp1 / 4;

     ARrsw_ay_iir = ARrsw_ay_iir . . .

    // backscaling

     ARrsw_ay = ARrsw_ay_iir ;

    // Limit lateral acceleration

    if (ARrsw_ay < -8191)

    { ARrsw_ay = -8191; }

    else

    {

    if (ARrsw_ay > 8191)

    {

     ARrsw_ay = 8191;

    }

    }

    }

    Register -- ARrsw_ay_iir

     ARrsw_ay -- Register

    Register -- ARrsw_ay

    Register COMP -8191

    Register-- -8191 ARrsw_ay -- Register

    Register -- ARrsw_ay

    Register COMP 8191

    Register -- 8191

     ARrsw_ay -- Register

    Register -- Register

    Register COMP -8191

    Register -- -8191

    Register COMP 8191

    Register -- 8191

    PseudoPseudoPseudoPseudo

     Assembler Code Assembler Code Assembler Code Assembler Code

    Using Global / StaticUsing Global / StaticUsing Global / StaticUsing Global / Static

    PseudoPseudoPseudoPseudo

     Assembler Code Assembler Code Assembler Code Assembler Code

    Using PassUsing PassUsing PassUsing PassParametersParametersParametersParameters

    Pass parameters need more stack and use an extra function call BUT

    Pass parameters save up to 40% runtime and RAM

    Note: Modern compiler may be able to do own optimizations (but this may

    depend on the selected optimization options at compile time)

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    87/97

    Page 87Copyright © 2010 Eberhard De Wille

    Module Design

    „Interfaces“

    SW Design for Safety Critical Microcontroller Applications

    Module Design: „Interfaces“ – Bad Example

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    88/97

    Page 88Copyright © 2010 Eberhard De Wille

    void PI_control (void)

    /* calculate current deviation [0.1mA] */

    w_ss = (S_SHORT)(o_cr_out3) - (S_SHORT)(o_cr_out3_act);w_p_anteil = _mul32(w_fct_p_out3, w_ss) >> 16; /* P calculation */

    w_i_anteil += _mul32(w_fct_i_out3, w_ss + w_err_1) >> 17; /* calc. I */

    w_err_1 = w_ss;

    if (w_i_anteil < 0) {w_i_anteil = 0;} /* limit I portion */else if (w_i_anteil > 20000) {w_i_anteil = 20000;}

    w_ss = w_i_anteil + w_p_anteil; /* duty cycle = P- + I-portion */

    if (w_ss < 0) {o_dc_out3 = 0;} /* limit/correct duty cycle */

    else {o_dc_out3 = _mulu32(w_cor, (U_SHORT)(w_ss)) >> 10;}

    /* limit duty cycle */if (o_cr_out3_act < 500){ if (o_dc_out3 > 7500){o_dc_out3 = 7500;}}

    else {if (o_dc_out3 > 9500){o_dc_out3 = 9500;}}

    drv_pwm3_set(); /* output duty cycle */

    Language Interface not used!

    Scattered Global Input Interface

    Scattered Global Output Interface

    SW Design for Safety Critical Microcontroller Applications

    Module Design: „Interfaces“ – Bad Example

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    89/97

    Page 89Copyright © 2010 Eberhard De Wille

    Allows access to any data outside of the function

    Global or static variables are mandatory for this

    kind of design, thus all the problems involved

    with global are inherited

    Interfaces are hard to detect and can change

    without noticing it

    Supports an unsynchronized control and data

    flow

    SW Design for Safety Critical Microcontroller Applications

    Module Design: „Interfaces“ – Interfaces to other Modules

    Outputs:

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    90/97

    Page 90Copyright © 2010 Eberhard De Wille

    T_UWORD ANAINGetFbaVolt(void)

    {

    iFbaSwitchVolt = ANAINGetAnalogChannel(7, 0);

    return(iFbaSwitchVolt);

    }

    void EMBUSMuxRx(TTPDataStruct * pTtpBusData){

    /*------------------- LOCAL VARIABLES -------------------*/

    T_UWORD MuxInfoIndexIn;

    T_UBYTE * pCounterAndIndex;

    /*------------------------- CODE ------------------------*/

    pCounterAndIndex = ((T_UBYTE *)(&pTtpBusData->w7)) + 1;FrameCounter = *pCounterAndIndex & 0x0F;

     pTtpBusData->Counter = FrameCounter;

    MuxInfoIndexIn = (US)(*pCounterAndIndex) >> 4;

     pTtpBusData->MuxArray[0][MuxInfoIndexIn] = pTtpBusData->w8;

     pTtpBusData->MuxArray[1][MuxInfoIndexIn] = 2;

    }

    Outputs:

    Inputs: (try to avoid them!)

    T_VOID ANAINSetTimer(T_UWORD time)

    {

    iAnaTimer = time;

    }

    Exception!

    SW Design for Safety Critical Microcontroller Applications

    Module Design: „Interfaces“ – Interfaces to other Modules

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    91/97

    Page 91Copyright © 2010 Eberhard De Wille

    Conclusion:

    • Good interfaces use only basic data types

    • If you have arrays or structures in the interface the design is not

    good! (drags data over the stack)

    • Good interfaces use only the function interfaces of C-functions

    • The number of interface functions of an object should be less than 20

    a good design has less than 10

    • Pointers to structures or arrays may be permissible in the interfaces,but indicate that there is a potential for a better design.

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    92/97

    Page 92Copyright © 2010 Eberhard De Wille

    Module Design

    „Documentation“

    SW Design for Safety Critical Microcontroller Applications

    Required Traceability (Overview)

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    93/97

    Page 93Copyright © 2010 Eberhard De Wille

    System

    Requirements

    System Test

    Spec

    System Test

    Report

    SW

    Requirements

    SW Architecture

    & Design

    SW Integration &

    Validation Test Spec

    Source Code

    SW Integration &

    Validation Test Report

    SW Module

    Test Spec

    SW Module

    Test Report

    Module and

    C-Function Names

    Module and

    C-Function Names

    Module and

    C-Function Names

    Reference of

    Req. ID, Perl Check 

    Search of

    Req. ID

    Reference of

    Req. ID, Perl Check 

    Search of

    Req. ID

    Reference of

    Req. ID, Perl Check 

    Search of

    Req. ID

    Reference ofReq. ID

    Search of

    Req. ID

    Module and

    C-Function Names

    Module Names

    Funct. Names

    Reference of

    Req. ID, Perl Check 

    Search of

    Req. ID

    Module Names

    SGML

    Example

    SW Design for Safety Critical Microcontroller Applications

    Possibilities of Design Documentation

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    94/97

    Page 94Copyright © 2010 Eberhard De Wille

    • WinWord or similar

    • Traceability manually by tables

    • SGML

    • Traceability by copies of requirements and automated checks

    • Model Based System Engineering (e.g. Enterprise Architect)

    • Traceability implicit by dependencies in models

    SW Design for Safety Critical Microcontroller Applications

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    95/97

    Page 95Copyright © 2010 Eberhard De Wille

    Design Pattern

    a few Thoughts

    SW Design for Safety Critical Microcontroller Applications

    Design Pattern: „A Definition"

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    96/97

    Page 96Copyright © 2010 Eberhard De Wille

    • Recurring solutions to common problems of design

    • Practical solutions to real world problems

    • The "best fit" and trade-off for a given set of concerns

    • A way of documenting "best practices"

    • A means of SW reuse and knowledge sharing

    • A means to build upon "lessons learned"

    • A "buzz word" and massively hyped!

    SW Design for Safety Critical Microcontroller Applications

    Design Pattern: „A Definition" – Kinds of Pattern

  • 8/18/2019 Software Design for Safety Critical Microcontroller Applications

    97/97

    Page 97Copyright © 2010 Eberhard De Wille

    • Analysis Patterns (recurring & reusable analysis models e.g. for requirements)

    • Organization Patterns (structure of organizations/projects, e.g. roles, CM)

    • Process Patterns (software development process at CMMI Level 3)

    • Domain-specific - Any other domain you can think of!

    • SW Design Pattern

    Architecture (e.g. layers and main components)

    Module Design (e.g. templates, OO concepts)

    Programming Idioms (detailed techniques/style)