Products and processes of all kinds are increasingly constructed to include one or more ’embedded’ systems to enhance functionality. Such embedded systems often combine software and hardware which together enable a distinct, dedicated and limited functionality, while not being as flexible as PCs, for example [Wiki]. ‘Embedded’ means that these systems are an integral part of the product/process.
In the present context, it is considered that there is much in common between embedded systems and measurement systems. In many cases, both types of system involve the acquisition and treatment of measurement information, from a sensor in contact with an object through signal conversion for control and regulation of a process. For instance, an embedded system in a vehicle whose purpose is to enhance safety and environmental protection will consist of a sensor monitoring one or more physical quantities (e.g. acceleration, exhaust gas emission), via signal conversion to enable feedback control of the vehicle.
Why test embedded systems?
As with any product, an embedded system can fail which in turn leads to product failure which can have more or less serious consequences.
Testing an embedded system – say, at the design or prototype stage – can identify what faults may occur throughout product lifetime:
- the type of fault,
- how probable
- cause (human error, production error, environmental effects etc)
If these factors are known, then the embedded system can be redesigned to hopefully minimise problems later in product life.
Quality of embedded system
The quality of an embedded system is some measure of the number and seriousness of defects or faults. The actual product quality will ultimately have to be matched to customer requirements. Where embedded system failure can lead to serious consequences, regulation and strict specifications of product quality are set and compliance based on testing of actual product with these requirements will need to be made both at initial type approval and subsequent verification.