SW Design PDF

SW Design for Safety Critical Microcontroller Applications
Software Design
for
Safety Critical
Microcontroller Applications
by Eberhard De Wille
Copyright 2010 Eberhard De Wille
Page 1

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
Page 2
Motivation:
Some Famous Software Bugs
Page 3

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 lowlevel pass. Three passengers - a woman and two children - were killed.
The pilot claims he was misled on the aircraft's true
height 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.
Page 4

Several 1985-7 deaths of cancer patients were due to overdoses of radiation. The reason was a
bug 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
Page 5

The 1988 shooting down of the Airbus 320 by the USS Vincennes was attributed to a
human 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
Page 6

Rounding error in Patriot Defense System leaves 28 dead and 98 wounded
An Iraqi Scud missile hit Dhahran

barracks, leaving 28 dead and 98
wounded. 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 with
elapsed 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 14hour continuous performance, not
100. Patched software
arrived via air one day later.
Page 7

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 seconds
A 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
Calculated
seconds
Seconds
Error in seconds
Deviation (meter)
3600
3599.9966
0.0034
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
Page 8
REMEMBER ALWAYS
You can not test quality into software
you have to design it into software!
Page 9
High Level Design

An Example of a bad Design
Page 10
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
Page 11

Possible Design By Chance:
1 SW Module
void PI_control (void)

D_PWM_duty_cycle
Global
Variables
void ISR(0x23) pwm (void)

void get_analog (void)
D_analog_input
void get_switch (U_CHAR)

D_switch_debounced
void main (void){
while(1) {
/* main control */
.....
}
}
Page 12

Problems of a Design By Chance: Difficult Portability 1 (cont.)
void get_switch(U_CHAR cm_tcu)
{
#define L_C_TM_DEB 30
static U_SHORT
l_tm_tr;
static U_CHAR
l_x_1;
static U_BIT
l_st_chk;
/*
/*
/*
/*
de-bounce time [ms] */

last transition time [ms] */
previous input level */
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 after
transition or init call */
x_sw = x_sw_raw;
/* input level is valid */
l_st_chk = 0;
/* clear deb. time check flag */
}
}
Page 13

Problems of a Design By Chance: Difficult Portability 2 (cont.)
static S_SHORT w_err_1 = 0;
static S_SHORT w_i_anteil = 0;
S_SHORT w_p_anteil;
S_SHORT w_ss;
S_LONG w_sl;
/*
/*
/*
/*
/*
old deviation of set and current */

variable for I portion */
working variable for P portion */
signed short working variable */
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 */
Page 14

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 */
Page 15

Problems of a Design By Chance: Bad Maintainability

*/
w_err_1 = w_ss;
drv_pwm3_set(); /* output duty cycle */
Page 16

Problems of a Design By Chance: Unclear Interfaces 1 (cont.)
Language interface not used!

S_SHORT w_p_anteil;
S_SHORT w_ss;
S_LONG w_sl;
/*
/*
/*
/*
/*

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

else
}
Input interface scattered over the code
Page 17

Problems of a Design By Chance: Unclear Interfaces 2

*/
w_err_1 = w_ss;
Input interface scattered over the code

Output interface scattered over the code
Page 18

Problems of a Design By Chance: Possible Cross Influences Global Variables
S_SHORT w_p_anteil;
S_SHORT w_ss;
S_LONG w_sl;
Do you see the error?

/*
/*
/*
/*
/*

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

else
}
Page 19
High Level Design

Requirements for a good Design
Page 20

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
Page 21

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
Page 22

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
Page 23

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)
Page 24
High Level Design

Features of a good Design
Page 25

Better Design: Defined Architecture - Overview
Frame Work
Operating System
OS Abstraction Layer
Functional
Library
Function
Block 1
Function
Block 2
Function
Block 3
C
Library
Physical Layer
HW Abstraction Layer
Microcontroller Hardware
Page 26

Better Design: Defined Architecture Aim for the Application SW
Frame Work
Functional
Library
Function
Block 1
Function
Block 2
Function
Block 2
C
Library
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
Page 27

Better Design: Defined Architecture HW Abstraction Layer
Purpose - Adaptation to the Microcontroller Hardware
Standard Interface to the Physical Layer
U_SHORT us_GetOnOffSwitchRaw(void)
{
U_SHORT
x_sw_raw;
HW Abstraction Layer
x_sw_raw = _getbit(P2,14);
return(x_sw_raw);
}
Adaptation to the Implementation

Adaptation to the uC Platform
Page 28

Better Design: Defined Architecture OS Abstraction Layer
Purpose - Adaptation to the Operating System
OS Abstraction Layer
Adaptation
To
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;}
}
}
Adaptation
To
Frame
Work
Page 29

Better Design: Defined Architecture Physical Layer
Purpose Presentation of Normalized Physical Values to the Application
Normalized Interface to 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 Layer
Interface to HW Abstraction Layer

Page 30

Better Design: Defined Architecture Frame Work
Purpose Perform the Control Flow of the Application
Interface to the OS Abstraction Layer
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 Work
Interface to the Application

Page 31

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
Page 32

Better Design: Defined Architecture C - Library
Purpose Provide Tested Standard Solutions for Repeated Tasks
Substitute the Standard C - Libraries
C
Library
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
Page 33

Better Design: Defined Architecture Benefits of Libraries
Function Block 1
Absolute
Shifting
Limitation
Function Block 2
Absolute
Limitation
Division
C-Library
Absolute
Shifting
Division
Limitation
RefLine
Function Block 3
1.
Generic functions
written only once
2.
Possibility to use all

or only some of the
code in the library
Shifting
Division
RefLine
Page 34

Function Block 1
C-Library
Absolute
Shifting
Division
Limitation
RefLine
Abs
Shift
Limit
Specific
Algorithms
Once the library

tested, only the
other SW functions
need to be tested
4.
SW changes do not
imply retesting the
library functions
used
Function Block 2
Abs
Limit
Div
Specific
Algorithms
Function Block 3
TEST
3.
Shift
Div
RefLine
Specific
Algorithms
Page 35

uC C164
C-Library
Absolute
Shifting
Division
Limitation
RefLine
Absolute
Shifting
Division
Limitation
RefLine
5.
Library accommodates
different versions of
same function
depending on uC used
6.
Algorithms can be
generally coded and
does not need to
change because of
changing the uC
uC TMS470
Absolute
Shifting
Division
Limitation
RefLine
uC ST7
Absolute
Shifting
Division
Limitation
RefLine
Page 36
High Level Design

Interrupts, Timing and
Operating Systems
Page 37

Non - Optimized Architecture of Pseudo Microcontrollers:
General Purpose CPU
Control
Registers
ADC Unit
uC IR Level
uC IR Level
Control
Registers
Timer /
CAPCOM Unit
uC IR Level
Control
Registers
ASC Unit
Control
Registers
SSC Unit
Page 38

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.
Page 39

Optimized uC Architecture:
Dedicated uC
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 Level
uC IR Level
uC IR Level
uC IR Level
uC IR Level
uC IR Level
Control
Registers
ADC Unit
Control
Registers
Timer /
CAPCOM Unit
Control
Registers
SSC Unit
Control
Registers
ASC Unit
Page 40

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)!
Page 41

Optimized uC Architecture: Example of IR assignments (1)
Page 42

Optimized uC Architecture: Example of IR assignments (2)
Page 43

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

2ms task
4ms task
Task
interruption
Cooperative Operating System

2ms task
delay
4ms task
1 ms
Page 44

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)
Page 45

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 higher
attention 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
Page 46

Operating Systems: Example of an OS Design for a Brake by Wire System
Page 47

200s 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 same
time 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 it
contains 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.
Page 48

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 run
first 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.
Page 49

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.
Page 50
Module Design
Page 51
Module Design
Object Orientation
Page 52

Better Design: Object Orientation Some Quotes
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 an
object that do not contribute to its essential characteristics."
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"
Page 53

Better Design: Object Orientation A simple Example
Interfaces of the Object:

Back support
Arm rest
Seat
Adjustment lever
5 Wheels
Hidden Properties of the Object:
Mounting screws, e.g. of the arm rest
Adjusting mechanism
Suspension
Seat filling, etc. etc.
Page 54

Better Design: Object Orientation A rough Conclusion / Definition
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 an
abstract object.
Boundaries (interfaces) have to be small and narrow. If they are not, the
definition of the object (s) may not be correct.
Page 55

Better Design: Object Orientation Another Example
Sensor Filtered
Data and Diagnostic Information
Sensor Filtered Data
Sensor Diagnostic Information
Sensor Object
Sensor Filtered Data
Sensor Diagnostic Information
Sensor Filtering
Object
Sensor Diagnostics
Object
Sensor Raw Data

Sensor Raw Data
Sensor Raw Data

Acquisition Object
Page 56

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).
Page 57
Module Design
Control Flow and Data Flow
Page 58

Module Design: Control Flow and Data Flow C.F. driven approach
OS function
(1ms)
Algorithm
Main Function
Get X-Sensor
Raw Data
X-raw
value
X-Sensor
Filtering
X-filtered
value
Algorithm
Term1
X-Sensor
abs calculation
X-filtered
abs value
Algorithm
Term 2
Black arrows are
control flow
Red arrows are
data flow
Fire flags
Algorithm
Weighting
Function
Term data
Page 59

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
Page 60

Module Design: Control Flow
and Data Flow D.F. driven Approach
Calculate Filtered
Sensor Value
Get Raw
Sensor Value
Term 1
Airbag fire
decision
Term 2
Term
Evaluation
Calculate Filtered
Sensor Value
Term 3
Get Raw
Sensor Value
Term 4
Calculate Filtered
Sensor Value
Note: the colors denote

that the functions belong
to different objects
Calculate Filtered
Sensor Value
Get Raw
Sensor Value
Get Raw
Sensor Value
Page 61

Module Design: Control Flow
and Data Flow
Optimized Version of
Data
D.F. driven Approach
Pre-processing
Calculate Filtered
Sensor Value
Get Raw
Sensor Value
Get Filtered
Sensor Value
Term 1
Airbag fire
decision
Term
Evaluation
Term 2
Get Filtered
Sensor Value
Term 3
Term 4
Note: the colors denote

that the functions belong
to different objects
Get Filtered
Sensor Value
Get Filtered
Sensor Value
Page 62

Module Design: Control Flow and Data Flow D.F. driven - Example
Fire
Matrix
Function
Fire
flags
Fire
decision
Fire flags
Algorithm
Main Function
Fire
descision
term 1
data
Term 1 data
Algorithm
Term1
Algorithm
Weighting
Function
term 2
data
Algorithm
Term 2
Term 2 data
Filtered sensor value and

Abs of filtered value
Filtered sensor value and

Abs of filtered value
Sensor filtered abs value
Sensor filtered
value
X-filtered
abs value
X-Sensor Filtering
X-filtered
value
Black arrows are

control flow
Red arrows are
data flow
X-Sensor
abs calculation
Sensor raw value

X-raw
value
X-Sensor
Raw Data
X-Sensor
Object
Page 63

Module Design: Control Flow and Data Flow D.F. driven - Example
Best possible encapuslation and object orientation without cross influences
among the code parts
Less RAM and runtime consumption because of avoiding global variables
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
Page 64

Module Design: Control Flow and Data Flow
Conclusions:
The use of the technical interface of the C programming language, with its
pass and return parameters is a prerequisite to achieve synchronization of the
control and data flow.
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.
Page 65
Module Design
Include Structure
Page 66

Module Design: Include structure Bad Example
Page 67

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 all
modules
Header of own library
functions
Project specific data types

Interfaces of other SW
layers
Interfaces of other SW
Modules (same SW
component)
Page 68

Module Design: Include structure Example of global data types
#define
typedef
typedef
typedef
typedef
typedef
typedef
T_VOID
unsigned char
signed char
unsigned short int
short
unsigned long int
long int
void
T_UCHAR;
T_SCHAR;
T_USHORT;
T_SSHORT;
T_ULONG;
T_SLONG;
//
//
//
//
//
//
//
void
8 bit
8 bit
16 bit
16 bit
32 bit
32 bit
unsigned
signed
unsigned
signed
unsigned
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.
Page 69

Module Design: Include structure Example of a macro include file
#define TRUE
#define FALSE
1
0
#define NULL
#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
Page 70

Module Design: Include structure Example of a project data type file
#define
#define
#define
AF_ub_MAX_REAR_THR
AF_ub_FILTER_16_8
AF_ub_HIGHBYTE
4
(T_UBYTE) 8
(T_UBYTE) 8
// max. thresh. for rear crash

// Shift from 16 bit to 8 bit
// 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
{
T_UBYTE p1;
T_UBYTE p2;
T_UBYTE p3;
T_UBYTE p4;
} S_FUZZYSET;
S_FUZZYSET
Page 71

Module Design: Include structure Conclusion
Use a defined structure which is well thought about
Do not let includes grow wild. Plan it and design it!
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
Page 72
Module Design
Encapsulation and General Structure
Page 73

Module Design: Design Example ADTs
ADT stands for Abstract Data Types. A Object Oriented Design Method
for the C-language. Described in the Microsoft Press 1980
Only one file which acts as header or as source code module
Usage:
#define HEADER
#include ADTxxx.c"
#undef HEADER
Separation of Exported (Public) and Private defines, data and functions

Get- and Set-functions as interface to other software
Private sub-functions only used inside the module itself
Since the header and source are combined in one file there will never be a
discrepancy between badly maintained files.
Page 74

Page 75

Page 76

Page 77

Page 78

Page 79

Page 80
Module Design
Data
Page 81

Module Design: Data Scope of Data
ModuleA.c
#define HOME
#include ModuleA.h"
#undef HOME
ModuleA.h
#ifdef PUBLIC
// No global variables to other software
#endif //PUBLIC
static T_UWORD Variable3;

T_UWORD Variable6;
#ifdef PROTECTED
#endif //PROTECTED
void function1 (T_UBYTE value)

{
T_UWORD Variable5;
#define PRIVATE
static T_UBYTE Variable2;
#endif //PRIVATE
}
void function2 (T_UWORD value)
{
T_UWORD Variable5;
}
Page 82

Module Design: Data Principles of Data to use
No global variables to other SW parts
Use local variables inside the functions as far as possible
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
ModuleA.h
#ifdef PUBLIC
#endif //PUBLIC
#ifdef PROTECTED
#endif //PROTECTED
ModuleA.c
#define HOME
#include ModuleA.h"
#undef HOME
#define PRIVATE
#endif //PRIVATE
Page 83

Module Design: Data Design Pattern for Static Variable Initialization
ModuleA.c
ModuleA.h
#define HOME
#include ModuleA.h"
#undef HOME
#ifdef PUBLIC
#endif //PUBLIC
T_VOID Init_ModuleA (T_VOID)

{
function2(INIT);
Variable1 = 0;
Variable2 = 0;
}
#ifdef PROTECTED
#endif //PROTECTED
void function2 (T_UWORD Mode)

{
T_UWORD Variable5;
#define PRIVATE
#define INIT 0
#define RUN 1
#endif //PRIVATE
if (Mode == INIT) {Variable4 = 0;}

else
{
// normal code for operation
}
}
Page 84

Module Design: Data Access to the Data in a Module via Get-functions
and Set-functions
ModuleA.c
ModuleB.c
#define HOME
#include ModuleA.h"
#undef HOME
T_VOID function2 (T_VOID)
{
T_UWORD Variable5;
//some code
Variable123 = Get_Variable1();
}
{
T_UWORD Variable5;
//some code
Set_Variable1(Variable5);
}
#define HOME
#include ModuleB.h"
#undef HOME
T_VOID Init_ModuleA (T_VOID)
{
Variable1 = 0;
}
{
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; }
Page 85

Module Design: Data - The resource problem with global/static variables
Pseudo
Assembler Code
Using Pass
Parameters
Register -- Register
Pseudo
Assembler Code
Using Global / Static
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 ;
Register -- ARrsw_ay_iir

ARrsw_ay -- Register
Register COMP -8191

Register -- -8191
Register
Register
Register
ARrsw_ay
-COMP
---
ARrsw_ay
-8191
-8191
Register
Register COMP 8191

Register -- 8191
Register
Register
Register
ARrsw_ay
-COMP
---
ARrsw_ay
8191
8191
Register
// Limit lateral acceleration

if (ARrsw_ay < -8191)
{ ARrsw_ay = -8191; }
else
{
if (ARrsw_ay > 8191)
{
ARrsw_ay = 8191;
}
}
}
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)
Page 86
Module Design
Interfaces
Page 87

Module Design: Interfaces Bad Example
Language Interface not used!
*/
Scattered Global Input Interface
w_err_1 = w_ss;

Scattered Global Output Interface

Page 88

Module Design: Interfaces Bad Example
Allows access to any data outside of the function

Supports an unsynchronized control and data
flow
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
Page 89

Module Design: Interfaces Interfaces to other Modules
Outputs:
T_UWORD ANAINGetFbaVolt(void)
{
iFbaSwitchVolt = ANAINGetAnalogChannel(7, 0);
return(iFbaSwitchVolt);
}
void EMBUSMuxRx(TTPDataStruct * pTtpBusData)
Exception!
{
/*------------------- 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;
}
Inputs: (try to avoid them!)

T_VOID ANAINSetTimer(T_UWORD time)
{
iAnaTimer = time;
}
Page 90

Module Design: Interfaces Interfaces to other Modules
Conclusion:
Good interfaces use only basic data types
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
If you have arrays or structures in the interface the design is not
good! (drags data over the stack)
Pointers to structures or arrays may be permissible in the interfaces,
but indicate that there is a potential for a better design.
Page 91
Module Design
Documentation
Page 92

Required Traceability (Overview)
Reference of
Req. ID, Perl Check
System
Requirements
Search of
Req. ID
Reference of
Req. ID, Perl Check
Search of
Req. ID
System Test
Spec
System Test
Report
Funct. Names
Reference of
Req. ID
SW
Requirements
Search of
Req. ID
SW Integration &
Validation Test Spec
SW Integration &
Validation Test Report
Module Names
Module Names
Search of
Req. ID
Reference of
Req. ID, Perl Check
Reference of
Req. ID, Perl Check
Search of
Req. ID
SW Architecture
& Design
SW Module
Test Spec
Module and
C-Function Names
Module and
C-Function Names
Source Code
SW Module
Test Report
Module and
C-Function Names
Module and
C-Function Names
SGML
Example
Page 93

Possibilities of Design Documentation
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
Page 94
Design Pattern
a few Thoughts
Page 95

Design Pattern: A Definition"
A "buzz word" and massively hyped!
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"
Page 96

Design Pattern: A Definition" Kinds of Pattern
SW Design Pattern
Architecture (e.g. layers and main components)
Module Design (e.g. templates, OO concepts)
Programming Idioms (detailed techniques/style)
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!
Page 97

SW Design PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SW Design PDF

Uploaded by

Copyright:

Available Formats

SW Design for Safety Critical Microcontroller Applications

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

SW Design for Safety Critical Microcontroller Applications

The operating system of the microcontroller was a bad choice.

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

SW Design for Safety Critical Microcontroller Applications

An Iraqi Scud missile hit Dhahran

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

High Level Design

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

Task - design a microcontroller software with the following features:

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

void PI_control (void)

void ISR(0x23) pwm (void)

void get_switch (U_CHAR)

SW Design for Safety Critical Microcontroller Applications

de-bounce time [ms] */

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

old deviation of set and current */

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

SW Design for Safety Critical Microcontroller Applications

/* calculate current deviation [0.1mA]

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

/* calculate current deviation [0.1mA]

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

Language interface not used!

static S_SHORT w_err_1 = 0;

old deviation of set and current */

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

SW Design for Safety Critical Microcontroller Applications

/* calculate current deviation [0.1mA]

Input interface scattered over the code

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

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

Do you see the error?

old deviation of set and current */

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

SW Design for Safety Critical Microcontroller Applications

High Level Design

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

SW Design for Safety Critical Microcontroller Applications

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

Copyright 2010 Eberhard De Wille

SW Design for Safety Critical Microcontroller Applications

if (i_eds110 > 7600){o_cr_eds1 = 760010; /* limit to max */}

if (i_eds110 > 7600){o_cr_eds1 = 760010; /* limit to max */}

if (i_edsl10 > 7600){o_cr_eds1 = 760010; /* limit to max */}