Page 27

EETE DEC 2014

Redefining Automated Test with open software and modular hardware How we interact with devices is changing. As the world becomes more software oriented, what we can accomplish increases exponentially. This shift should apply to our test equipment, too. Unlike traditional instruments with predefined functionality, the NI automated test platform provides the latest technologies to build complex systems while reducing development time and cost. >> Accelerate your productivity at ni.com/automated-test-platform Follow us on Search National Instruments or LabVIEW Austria 43 662 457990 0 n Belgium 32 (0) 2 757 0020 Czech Republic, Slovakia 420 224 235 774 n Denmark 45 45 76 26 00 Finland 358 (0) 9 725 72511 n France 33 (0) 8 20 20 0414 n Germany 49 89 7413130 Hungary 36 23 448 900 n Ireland 353 (0) 1867 4374 n Israel 972 3 6393737 Italy 39 02 41309277 n Netherlands 31 (0) 348 433 466 n Norway 47 (0) 66 90 76 60 Poland 48 22 328 90 10 n Portugal 351 210 311 210 n Russia 7 495 783 6851 Slovenia, Croatia, Bosnia and Herzegovina, Serbia, Montenegro, Macedonia 386 3 425 42 00 Spain 34 (91) 640 0085 n Sweden 46 (0) 8 587 895 00 n Switzerland 41 56 2005151 UK 44 (0) 1635 517300 ©2014 National Instruments. All rights reserved. LabVIEW, National Instruments, NI and ni.com are trademarks of National Instruments. Other product and company names listed are trademarks or trade names of their respective companies. 14594 which identifies five aspects of software trustworthiness: safety, reliability, availability, resilience and security. The BSI document describes a widely applicable approach to achieving software trustworthiness rather than mandating any specific practices or procedures. The standard calls for an appropriate set of governance and management measures to be set up before producing or using any software which has a trustworthiness requirement. Under the regime, design teams need to perform risk assessments that consider the set of assets Proof of implementation as checked within asureSIGN’s plan editor. www.electronics-eetimes.com Electronic Engineering Times Europe December 2014 27 14594 Redefining Auto Test EET 91x277 Euro.indd 1 24/11/2014 11:03 to be protected, the nature of the adversities that may be faced and the way in which the software may be susceptible to such adversities. To manage that risk, appropriate personnel, physical, procedural and technical controls need to be deployed. Finally, PAS 754 demands a regime be set up to ensure that creators and users of software ensure that governance, risk and control decisions have been implemented. Where devices are likely to be incorporated into systems that have a safety aspect, certification to one of the relevant standards will be needed. This may be a generic standard such as IEC61508 or a domain-specific standard derived from it such as ISO 26262 that has been embraced by many of the automotive OEMs. A key element of the safety standards is the appropriate selection of a safety integrity level (SIL) to act as a guide for the degree to which functionality needs to be tested during design, during production and in the field, as built-in self-test mechanisms may be needed to ensure the device is fit for purpose. For example, a sensor node may include software to check its inputs are within bounds and not indicating a failure caused by too much dirt or a lost connection. SILs differ slightly according to the relevant standard but follow a similar structure. In ISO 26262, for example, the automotive SIL (ASIL) ratings cover the four letters A to D, as well as QM for no safety impact. ASIL A is for systems that have little safety impact up to D for the most critical functions, such as brakes and steering. In IEC 61508, the SILs are numbered but cover similar grading of criticality. The SIL determines the level to which each system needs to be tested. But to ensure that external problems cannot upset the more safety-critical systems, the engineering team has to go through a process of determining what could possibly affect the system they are designing, including events from external equipment. This calls for functions that check inputs as well as outputs for problems so that errant data does not cause the system to react unpredictably. An overarching test strategy needs to support those higher-level tests as well as the unit tests that will usually be performed during function creation and integration.


EETE DEC 2014
To see the actual publication please follow the link above