System,Safety and Software

“Safety is a system issue”(Nancy Levenson). Any system is made of subsystems, components etc. Each subsystem, component contributes to system safety. Hence the system has to be analyzed as a whole with safety in mind. There are techniques like – Fault Tree Analysis( FTA), Software FTA, Failure Mode Effects Analysis( FMEA) etc available for carrying out the analysis.

Note that software is also one of the important components of any system. The software safety needs can be derived from the system safety needs. Some of the typical needs are – software should prevent the system from entering an unsafe state by detecting error conditions, handle wrong user inputs etc.

Generally safety issues are considered as part of the non-functional aspect of the system. Some of safety related needs can be identified from a systems safety analysis System safety analysis usually involves – identifying hazards , their consequences and their causes. The hazards are then analyzed to see if they can be avoided altogether. Many times it is not possible to avoid them. They are then analyzed to see if they can be controlled or eliminated if they do happen. Control mechanisms should also be identified for controlling, eliminating them. Some of the techniques are listed below:

• Safety interlocks
• Hardware lockouts to protect against software errors
• Watchdog timers
• Hardware monitor circuits
• Continuous Built In Tests
• Software check points for recovery

From the system safety needs and safety analyzes, software safety needs to be derived. The software needs thus developed needs further safety analysis. The purpose of this analysis is to identify:

• To verify that the software safety needs are correct
• Software correctly implements the safety related features

With all these, it is still difficult to achieve the required system safety. So, the software can include the following features to make it more safer

• Built in tests
• Heart-beat monitors
• Using pre conditions, post conditions for filtering wrong inputs
• Checking for buffer overflows
• Continuous built in tests
• Checking for wrong or invalid commands
• Checking for out of order data / commands
• Entering a wrong state due to multiple events etc

The question still remains how to identify the system failures and hazards. Some of the guidelines for identifying these are:

• Explore historical records
• Look at energy sources
• Develop “what-if” scenarios

 

There are many known sources of software safety problems that can be addressed explicitly by adding them as requirements. Some of them are listed here for reference.

• Use of wrong engineering units
• Assumptions about the environment
• Assumptions about users
• Assuming that inputs are always correct
• Not following relevant standards

This entry relies on the following sources. These can provide you more information on the subject: http://satc.gsfc.nasa.gov/assure/nss8719_13.html
A Software Fault Tree Approach to RequirementsAnalysis of an Intrusion Detection System
Guy Helmer et al

 

 

Concurrent programming gets a new lease of life

Concurrent programming has been around for some time now. Programmers have been writing multi-threaded applications wherever they can. So, what has changed now?

According to Herb Sutter, the free lunch is over. Processor manufacturers had been coming up with faster and faster processors for some time. But, now, it looks like they have hit the physical limit. Now processors aren’t getting any faster anymore. Instead, the processor manufacturers are now putting more than one processor on a single chip i.e multicore processors. What difference does that make to us? According to Herb Sutter it is going to change the way we program, think about the program logic, debug, test etc. He has summarized the trends:

1. Applications will increasingly become concurrent if they want to fully exploit the CPU throughput
2. Applications are likely to become increasingly CPU bound
3. Efficiency and performance will get more important
4. Programming languages and systems will increasingly be forced to deal with concurrency

People who are familiar with lock-based programming might think that moving their programs to new multi-core systems should work just fine. This, however, need not be true. The true parallel execution might expose some of the inherent race conditions. They need to prepared for some surprise if they move their so called ‘concurrent application’ to multi-processor systems. This trend will force people to think in a different way i.e think in terms of concurrency. People still need to carefully design their applications for achieving better performance as before. The complexity of algorithms still matter.

Some of the tricks that can speed up your application include:

• Data-structures should be designed such that less or no synchronization needed for accessing them from different threads
• Application’s working set should, as much as possible, fit into the cache. This reduces the memory access and speeds up the application
• Perform loop optimizations
• Try to reduce the algorithm complexity. If you can reduce your algorithm complexity from O(n2) to O(n long(n)) you will witness significant speed up
• Align data ( 32 or 64 byte boundaries depending on the machine architecture)
• Use compiler features for exploiting processor architecture related features
• Some operations can be made faster using SIMD, MIMD instructions