1
Scania
Software development and testing
Thomas Gustafsson
thomas.gustafsson@scania.com
2
Agenda
• Real-time problems and their solutions in industry
• Some examples from my career
• General info about Scania
• Software development at Scania
• Scania’s electrical system
• Integration testing
3
Main message
• Scania is a software company
• Scania has a high degree of in-house development of ECUs
• A lot of freedom and possibilities to learn new things
4
Real-Time in Industry
• How can real-time aspects in software be addressed?
• 3 cases and a pattern
• Car seat heater
• Energy meter
• CAN bus load in a vehicle
• Actor pattern
Info class Internal
RESA/Staffan Persson Releaseprocessen
Utgåva 1, 2009-03-31
5
Car seat heater
• Four step input as an analog value
• Translate into a digital signal and transmit it to an ASIC
• 90% of code is error handling
• The end customer, a big european car manufacturer, had
software development process requirements, e.g., the use of
MISRA C code guidelines
• But also, how is the event of bursting interrupts handled
Info Class Internal
Your date here
Department/Name/Subject
6
Car seat heater
• How do you avoid having to prove that you handle interrupt
bursts corrrectly?
• You don’t use interrupts at all!
• So you use a time-triggered architecture instead, then no
need even for timer interrupts
• Slot 1
• Start free running timer
• Execute code
• Wait for timer to reach 4 ms
• Slot 2
• …
Info Class Internal
Your date here
Department/Name/Subject
7
Car seat heater
• If we can prove that no slot takes longer than 4 ms, then we
are safe and have a completely deterministic solution!
• Count assembler instructions and assume for loops take
maximum amount of iterations
• We still had a wide margin even though a software
implementation of division algorithm
Info Class Internal
Your date here
Department/Name/Subject
8
Car seat heater
• A time-triggered software architecture has some nice
properties
• it is fundamentally different compared to event-based
architecture
• once you have decided for this approach, it is hard to
refactor into event-based architecture
• the other way around is harder
Info Class Internal
Your date here
Department/Name/Subject
9
Energy meter
• Accumulate energy transfered in an electricity grid. Billable
quantity which is regulated. The software development
process is also regulated
• Strict timeliness requirements
• Must measure current at fixed sampling intervals relative
to start of a sine wave
• So this is a hard real-time system
Info Class Internal
Your date here
Department/Name/Subject
10
Energy meter
• Software split into two parts
• Hard real-time
• Soft real-time
• Hard real-time
• Time-triggered approach would be impossible due to the
short slot times
• This part determines current energy and accumulates it
• Prioritized interrupts is used
• Soft real-time is realized using tasks in an operating system
• E.g., HMI and communication protocols
Info Class Internal
Your date here
Department/Name/Subject
11
Energy meter
• Pattern heavily used giving independent threads
• class FuncA : public Thread {};
• FuncA a = new FuncA;
• a->execute();
• What is the main problem with the above pattern?
• Each thread requires memory allocated for its stack
• The stack size must be fitted against the deepest possible
call graph
• This call chain might never be used in practice
• Lots of precious memory allocated unnecessarily
Info Class Internal
Your date here
Department/Name/Subject
12
Energy meter
• No real-time analysis was done
• It was known that high prioritized interrupts would be able to
handle the hard real-time part
• The soft real-time part had to do with what CPU cycles were
available
• Testing during development phase showed that performance
was good enough
• Theoretical analysis was done of wear leveling of serial flash
Info Class Internal
Your date here
Department/Name/Subject
13
Bus load in a vehicle
• Scania is using results from:
• R. I. Davis, A. Burns, R. J. Bril, and J. J. Lukkien,
“Controller area network (CAN) schedulability analysis:
Refuted, revisited and revised,” Real-Time Systems, vol.
35, no. 3, pp. 239-272, 2007.
• This paper highlights that old proofs were wrong, and then
corrects them
Info Class Internal
Your date here
Department/Name/Subject
14
Bus load in a vehicle
• Response time analysis is used
• The longest response time shall be found
• It is shown that the busy period occurs when the longest
lower priority messages has started to be transmitted, at the
same time as message i and all its higher priority messages
are queued for transmission
• Now i must wait for the lower priority message and all higher
priority messages
• The busy period contains the longest response time
• Each instance of i within busy period must be investigated
Info Class Internal
Your date here
Department/Name/Subject
15
Bus load in vehicle
• CAN is logged during each test script
• Response time analysis is automatically performed for each
test suite
• Max observered CAN bus load is measured
• These two metrics are used as a guidance of the status of
the electrical system
Info Class Internal
Your date here
Department/Name/Subject
16
Distribution of real-time data
• Total ordering of messages sent on independent CAN buses
• CAN buses are connected to distributed computers
• How do we get a notion of global time?
• We need a synch bus where a synch message is sent.
The property of CAN is that the message is received in all
nodes simultaneously
• Now the time bases in each distributed computer can be
normalized
17
Distribution of real-time data
Synch bus
computer
computer
computer
Merged
stream
merger
18
Distribution of real-time data
• One program for sending synch messages
• One program per computer for receiving and forwarding
CAN frames
• One program for sorting frames in correct order
• One program for visualizing CAN frames
19
Summary real-time in industry
• Real-time is more of a development process issue rather
than a theoretical issue
• or at least that is how it is handled in industry
• test as much as possible
• make small iterative steps so you always go from
something that is working
• Software In the Loop (SIL): run the full system as early as
possible
• The theoretical results of, e.g., Bril is, however, used
Info Class Internal
Your date here
Department/Name/Subject
Corporate statement
Scania’s goal is to deliver optimized heavy trucks, buses,
engines, and services, offer our customers the best total
economy and thereby be the leading company in our business
segment. The foundation is Scania’s core values, our focus on
methods and our motivated coworkers.
Haulage
Construction
Distribution
Special purpose
Premium products and services
Network and services
Intercity and coach
City and intercity
Engines
Modular product system
23
R&D Factory
Scania Technical Center
25
SESAMM – Scanias electrical system
26
Scania Electrical System - Principles
•One common electrical system for all vehicle types
•Function allocation independent of vehicle specification
•Backward compatible
•Rebuildability
•High level of functionality in degraded mode
•Segments
•In-house development of SW in strategic nodes
•CEPPSS (Continuous Evolution of Properties Planned in Small
Steps)
27
User Functions
– A User Function describes a vehicle function from which the user has a direct benefit
–The complete set of User Functions describes Scanias electrical system
Opticruise –
UF 493 ”Transmission automatic”
More examples:
UF 352 ”Bus Stop Brake”
UF 415 ”Hill Hold”
UF 511 ”Rear Wheel Steering”
28
Allocation Elements
– An Allocation Element describes a logical component of a User Function as implemented in
an ECU
UF
AE
AE
AE
CAN
ECU
ECU
Benefits
•
Scalable
•
•
•
• Possibility to add systems and segments for increased content
Modularised
•
Encapsulation and modularisation reduces communication need and complexity
•
Possible to chose degree of centralisation
• Clear organisational responsibility for components and functions
Evolution
•
•
Few ECUs on low cost vehicles
CEPPSS
• Balancing complexity and backwards compatibility
Testing
•
ECU system level testing possible locally before delivery to integration test
•
• Stepwise integration possible
Isolation between ECU systems
•
• Easier to prove freedom of interference and avoid unnecessary mixed criticality
Flexibility in subsegments
•
•
Possibility to adapt interfaces quickly to new systems without affecting main segments
• Often in-house SW in main nodes
Builds on proven concept
29
30
Release process
CR
CR
CR
CR
CR
 Release process is a flow with a pulse
 Each planned change is flagged with a CR
Abbreviations:
CR = Change Request, P1 = Integr.test 1, P2 = Integr.test 2, P3 =Integr.test 3
31
Test environments for integration testing
12/11/2015
32
I-lab: Hardware-In-the-Loop
Electrical signals
Electrical signals
System under test
HW+ SW
Fault
injection
HW
Signal
handling of
sensors
Dynamic vehicle model
Fysikaliska signaler
Load
simulation
Signal
handling of
control
signals
Fault
injection
33
Haulage
Construction
City traffic
Long range
SOPS
+
~180 TC
Test report
~250 TC per night
34
Real-time in HIL
• The test scripts, running in a PC connected to the HIL, have,
normally, no real-time requirements
• All real-time requirements are executed in the processor
boards in the HIL
• Captured/recorded data may be analyzed in a test script
• Such data is recorded on ms basis
• and is properly aligned between processor boards
Info class Internal
RESA/Staffan Persson Releaseprocessen
Utgåva 1, 2009-03-31
35
Main problems in testing
• Not so much real-time issues
• but scalability issues, since we use the world’s largest HIL
• model is so big that Matlab, simulink and C compilers may
crash in the build process
• 64 bit versions of these tools are a must
• Tools for studying and manipulating real-time values may
crash
• 64 bit versions not available yet
• Time consuming to adopt HIL for new electrical system
Info Class Internal
Your date here
Department/Name/Subject
What happens when a new ECU is
introduced?
•
•
•
•
•
36
Model needs to be adapted
HIL hardware must be adapted
ECU must available for testing the adaptions
Who tests the test environment?!
So we need to start the integration work several years before
SOP
Info Class Internal
Your date here
Department/Name/Subject
37
Software development of test environment
• Agile but not SCRUM
• Planning every two weeks with demo and retrospective
• Daily 15 min meetings
• Continuous Integration
• Automatic execution of unit tests and pylint after check in
to VCS
• Creation of generic software architecture needing as little
maintenance as possible
Info Class Internal
Your date here
Department/Name/Subject