Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Transcript of Untitled Prezi
Software Testing & validation
Embedded system in Automotive
ARIANE 5 - Flight 501 Failure
On 4 June 1996, the first flight of the Ariane 5 launcher ended in a failure , Only about 40 seconds after initiation of the flight sequence, at an altitude of about 3700 m, the launcher veered off its flight path, broke up and exploded.
Embedded System == control applications
so you need good command of embedded systems
Software + Hardware
Embedded systems are the hardest phase in the industry not ( mechanics or electronics ) and takes most of the time and the money
Embedded systems = Art + science , it takes a lot of experience to be a good embedded engineer
In the field of the embedded system you will need a good knowledge in
Real time operating system
Testing and validation
Testing and Validation is the hardest , you need to imagine whats going wrong , although there are now real time debuggers (ex. check TI stellaris launch pad )
Embedded systems concepts
Failure examples in Embedded system
Testing and validation
safety critical Embedded systems
Real time operating system
its a real time operating systems you can use it to apply multitasking on a single core processor ,depending on the kernel ( heart of operating system ) varies the behavior
kernel may vary to :
-priority based ( preemptive ,non preemptive).
-or combination between them
RTOS is widely used in industry, but this can introduce several problems regarding safety
1- critical sections of memory
2- usage of controller peripherals
but every RTOS implements a mutex/semaphore and more features to overcome those problems
C/C++ with few consideration for safety for the embedded systems, one obvious thing is that you should never use dynamic memory allocation
Types of testing
unit testing-component testing
Unit testing Basic idea
basic idea, procedure used to validate that particular module of source code is working properly
so you need to make sure all cases and corner cases will not to lead in failure for the embedded system hardware and/or its functional purpose
stubs: are very useful when application is not available yet ,no need for other modules, hardware module is not ready also ,stubs only care about end result but not how we get there
Mocks : it has an extra feature , that it also take care about the behavior ( when the function is called etc )
choosing between them depending on your test cases , also on what makes your code simpler
stubs vs mocks
for safety related codes its not about only the (in, Out ) relation but the code execution path shall be as designed
unit testing relies on :
test harness :the code which executes the test cases to test the unit under test ,there are test automation tools that can do this for you , the automation derives the test cases from analysis of your code and has no knowledge of the semantics implemented in it.
how to develop test cases?
its kind of art + science,and requires a lot of experience
functional testing : Functional testing (also known as black-box testing) selects tests that assess how well the implementation meets the requirements specification,it should come first.
coverage testing : (also known as white-box testing) selects cases that cause certain portions of the code to be executed, so it is reserved for testing a completed or nearly completed product
an algorithm can be possible for developing test cases
start with function testing
1. Identify which of the functions have NOT been fully covered by the functional tests.
2. Identify which sections of each function have not been executed.
3. Identify which additional coverage tests are required.
4. Run new additional tests.
Unit testing (continued) :
test stubs : optional( functions , macros), represents simulation of real world events called from unit under test
test instrumentation : output documentable traces of execution ,exposing its behavior
It isn’t enough to pass a test once. Every time the program is modified, it should be retested to assure that the changes didn’t unintentionally “break” some unrelated behavior
-this is called regression testing
Developing safety critical real time embedded systems :
systems that must prevent humans and environment from exposing to dangers
time : the correctness of the system does not only depend on the outputs but also meeting the time when result are produced
real : the reaction to the outside events ,must corresponds (same time scale ) for measuring time in the controlled environment
system requirements :
functional requirements : outputs and inputs
non-functional requirements :time to compute ,code density, and reliability and repeatability for safety critical systems is a must , size , power consumption
hard vs soft real time :
hard : means that missing some functions dead line may lead to catastrophic consequences ex. (air bag - vehicle braking system)
soft : meeting the time constrains is desirable, but missing a time tick or two may not be catastrophic (displaying messages on a screen )
“AUTOmotive open System Architecture “
What is AUTOSAR ??
Automotive software architecture developed by automotive manufacturers and is being developed by automotive manufacturers through three phases to simplify the development of automotive applications
1-Enables development of independent software components
2-Demonstrate how different functions can be operated on the same (ECU) “electronic control unit” .
3-Separate hardware from software to allow software reuse .
4-Reduce overall software cost .
5- Provide safety for automotive embedded systems.
SAFETY FEATURES AND TECHNIQUES
1- Memory partitioning concept : separate software applications on the same (ECU)
2- DUAL (Microcontrollers) : provide back up Microcontroller to discover faults
3- Program flow monitoring : check the timing and the logical result of every step in the program
Examples of hardware SAR interfaces:-
1- Anti-Lock Braking system (ABS)
2- (ESC) electronic stability control
3- Automotive four-wheel drive
4- Engine injection control
5- HMI “ HUMAN MACHINE INTERFACE “ applications : multimedia ….. etc
• VFB: virtual function bus , IT shows how building software blocks for applications is done
• The applications are built up by several software components that can be distributed through (ECU)
• Example : Rain sensing application in cars collect data about the weather conditions then send these data to be computed , at the end the ECU sends the signal to wind sweepers motors to work
Errors in AUTOSAR can be handled directly by basic software or the interference of the original software developer is needed
IN Detailed level :-
1- The errors handled by the basic software level follows the process of
(FDIR) FAULT , DETECTION, ISOLATION ,RECOVERY
2- Applications error management defines the error model as described in the table above mainly it focuses on the external “ transient and permanent” but the design error that slip through verifications is also considered.
What could be the reason behind the sudden change in flight path of the first flight of the Ariane 5?
Certainly, reusing similar software code as in the previous Ariane 4 project without simulating was a big mistake.
• An operator error occurred due to an unexpected high value of the horizontal velocity sensed by the platform.
• The value was much higher than expected because the early part of the trajectory of Ariane 5
differs from that of Ariane 4 and results in higher horizontal velocity values.
• during execution of a data conversion from 64-bit floating point to 16-bit signed integer value.The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer.
• This resulted in the operand error, causing the on-board computer to send diagnostic data instead of real flight data.
• This diagnostic data commanded sudden nozzle deflections and induced a high angle of attack.
• A simulation of the whole trajectory (static code analysis) should have pointed out the overflow error immediately.
• This step should have been performed at the stage of architectural design or implementation (prototyping) within the design process.
• On February25, 1991 ,failed to track and intercept an incoming Iraqi Scud missile.
• Killed 28 soldiers and injuring around 100 other people.
• Cause of the failure: software problem
About software problem:
• Inaccurate calculation of the time since boot due to computer arithmetic errors.
• the accuracy of the time variable was less than what is needed
Solution of the problem :
• It’s important to analyze the number of bits used to represent physical parameters, i.e. time, in the design.
systems failed due to embedded system
How AUTOSAR handles errors?
-Concepts of real time operating systems
-Art of testing and validation
-investigation report AX001-1-2 (may 2004)
CO-OPERATE ON STANDARDS
COMPETE ON IMPLEMENTATION.