Post on 07-Jul-2018
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)