Why is Software Tool Qualification Indispensable in ISO 26262 Based Software Development?

Software Tools, to a large extent, automate the tasks needed to be carried out during the ISO 26262 mandated safety lifecycle. However, they may also introduce errors in the form of fault-injection or non-detection of faults in the software.

For instance, a source code repository used in the project may get corrupted or a static analysis tool like LDRA may create false positives for errors in the code. To avoid such risks getting introduced in the software, ISO 26262 standard recommends tool evaluation and qualification.

Clause 11 of Part-8 of the ISO 26262 standard comprises the tool evaluation and qualification methods. As per the standard, tool qualification is a two-phased process that begins with the tool evaluation where Tool Confidence Level is determined and is then followed by Tool validation.

A natural question that pops in the mind is, ‘Do all the tools require qualification for every project?’

Well, a simplistic answer to that question is yes! A more nuanced answer would be that it depends on the particular use cases, software requirements and project specific workflow. It might be possible that a tool requires qualification in one project and does not in another. The question to be asked here is, “Will the tool introduce an error in the software?” If there is a possibility of error introduction, the tool must pass through the scrutiny.

What is ISO 26262 Standard’s Approach to Software Tool Qualification?

As already mentioned, Part-8 of the ISO 26262 standard contains detailed guidelines on software tool qualification. The objective is to get evidence suggesting that the tool in question is suitable for safety-related software development. The different use-cases analysed during the tool evaluation process are documented as evidence.

A Snapshot of one such document is shown below:

Certain terms such as Tool Impact, Tool Error Detection and TCL can be seen in this snapshot. We will explain them in detail as we proceed further.

These use-cases help in the evaluation of the following aspects:

• Does a malfunctioning software tool and its wrong output violate any safety-goal derived during HARA?
• What is the probability of a software tool detecting errors in the output derived from the tool?

The analysis of these use-cases helps derive the Tool Confidence Level (TCL). The TCL along with ASIL assigned to the project is used to determine the right method for tool evaluation. We will discuss the methods while explaining the work products required for ISO 26262 software tool qualification.

The first step in the process of tool qualification is the planning of the usage of the tool. From the configuration of the tool to its use cases and execution environment, a plethora of information is required at this step.

A gist of information that must be available to ensure proper tool evaluation:

• Description of features, function, and properties of the tool
• Environment required for the tool operation
• Known malfunctions of the tool and associated safeguards
• Known expected behaviour of the tool under anomalous working environment

Now comes the analysis part. This process is also called Software Tool Classification Analysis

This analysis is required to determine the Tool Confidence Level (TCL). In order to derive TCL, tool impact and tool error detection need to be understood.

Tool Impact: If a tool can introduce faults in the software or fail in detecting the errors, the tool is considered to impact the final software. In such a case, the Tool Impact is denoted by TI 2. If the tool is not impacting the final software output, its falls in the category of TI 1.

Let us understand with an example. LabView tool is a test automation tool used to validate the functionality of a controller such as Torque-speed characteristic. As it is an important task, this tool impacts the final software. Hence, it is classified as TI 1.

Tool Error Detection: The use-case scenarios of the tool decide whether there are enough safeguards in the tool to prevent and detect malfunctioning and erroneous output. This capability of the tool decides the error detection confidence level.

The ISO 26262 Functional Safety experts take multiple factors into consideration while assigning Tool Detection levels. For instance, an IDE called CS+ may have a tool error detection level of TD 2 (medium) due to its incapability of detecting all the errors in the code. Another code generator for which the output code is tested according to ISO 26262 standard, can be given a TD1 level (High confidence).

There is another scenario where a different software tool is used to verify the output from a software tool. In such cases, the interdependence between the tools is also considered.

Tool Confidence Level:

When TI and TD are established, Tool Confidence Level can be determined using the following schematics.

TCL 1 is the lowest level of confidence. Tools assigned this level do not have high impact on the quality of the final product. Therefore, tool qualification is not required.

TCL 2 and 3 are medium and high level of confidence, respectively. A tool qualification is required to demonstrate tool reliability.

And when we have the TCL, we refer to the ISO 26262 standard Part-8 Table 4 and 5 to understand which Tool Qualification Method applies.

Tool Qualification Methods Mandated by ISO 26262

The tool qualification methods prescribed in the standard for TCL 2 and TCL 3 are almost similar, with a slight difference based on ASIL value.

The tables will make it clearer.

Let’s understand these methods and how they are applied for ISO 26262 tool qualification.

1. Increased Confidence from use: The confidence is derived from previous use of the tool under similar development environment and use cases. There is an increased evidence only when the similar version of the tool has been used for the same purpose with similar functional constraints. Also, the data collected from the tool’s previous usage must be adequate. If these conditions are not met, this method is not applied. As the software tool versions upgrade very frequently, this method is not among the most used ones.
2. Evaluation of the tool development process: This method relates to the appropriate standard applied during the development of the tool itself. In most cases, the tool evaluation team does not get in touch with the tool developers and assess their development process. However, the tool developers do get their tools certified by organizations such as TUV.
3. Validation of software tool: Validation of the software tool is a method that is required for higher ASIL compliance (ASIL C and ASIL D). Also, the test suites must be designed to evaluate both functional and non-functional aspects of the software. The standard states that the tool validation can be performed by either the tool vendor or the tool’s end-users.
4. Development in accordance with ISO 26262 standard: This method is rarely applied as a majority of software tools are PC based and are not developed as per ISO 26262 standard.

*For ASIL B, C, and D, an additional step of confirmation review as per Part2 of the ISO 26262 standard must be carried out. Different levels of confirmation review are applied as per the ASIL.

Conclusion

Tool qualification is a joint task for both the tool vendors and the users. Although tool qualification must be performed by the user with respect to specific projects and use-cases, the tool vendors can do their bit to make the process easier and less time-consuming.

IoT Security – Part 2 of 3: Analysis of Gateway Security in an IoT Infrastructure

In part 1 of this blog series Principles of Holistic Security and End Point Security Elements, we introduced to you the basic components of an IoT infrastructure. We also explored holistic IoT security principles and how end point security can be implemented at the IoT device level.

In this blog, we will look at the different components of gateway security to protect IoT gateway devices in the infrastructure.

IoT Gateway Security

The IoT gateway is basically a bridge between the devices with sensors and the cloud. IoT gateway solutions may also offer local processing and storage capabilities.  Additionally, gateway devices can control field-deployed IoT devices based on the sensor input data.

Since an Edge Gateway is located between the local intranet and external internet, it is a critical point for network connectivity. The gateway also has higher processing power than field-deployed IoT controllers (retrofitted with sensors). This implies that the gateway has superior software that, in turn, is vulnerable for hackers to exploit. Hence, it is crucial that the gateway is adequately protected.

IoT gateway security includes the incorporation of security features at multiple layers. Let us take a look at these in detail:

• Device hardware/software level
• Bluetooth PAN level
• WAN level security

Device hardware/software level

The hardware and software security measures for a gateway device are similar to that for the IoT sensor devices. We have explained this in part 1 of this blog series; so we will not go into the details here.

Here is an overview of security elements at the gateway hardware and software level.

• Physical and Tamper security
• Secure Boot and Root of Trust
• ASLR
• Guard band in OS
• TPM/HSM
• Chip Security
• Disable debug access

Bluetooth Personal Area Network (PAN) level security

As far as PAN level security is concerned, there are several security components that can be incorporated in the system:

• Access Control Models – Access control models for an IoT environment are usually classified according to the basis for access control. Hence, you can have Role-based access control, Usage control, Attribute-based access control, Capability-based access control or Organizational-based access control models, to name a few. These models ensure that there is easy identification to enable execution of tasks permitted for each entity/user.
• Blacklisting/Whitelisting of Bluetooth MAC Addresses – It is possible to create a list of denied/allowed wireless clients that can connect to the device based on their MAC addresses. MAC addresses that are included in the whitelist will have access to the device, and all other clients are denied the access. Conversely, MAC addresses in the blacklist will not have access to the device, while all other clients are allowed access.
• Firmware Update Administration – Whenever there is a firmware update on the gateway device, there should be strong authentication mechanisms. Ideally, the firmware update should be cryptographically signed, and the gateway should be able to verify the signature before the firmware update process.
• Logging and Usage Meters – IoT data can be effectively managed and used by organizations for generating security intelligence through Artificial Intelligence (AI) technology. Data can be easily collected, organized and processed through logging or usage meters. Device logs will provide information such as connections, errors and other such lifecycle events. The results gained from this raw data can be utilized for reinforcing the security of the IoT ecosystem.
• Control Pairing/Bonding – BLE pairing is the process in which temporary keys will be found and exchanged with a Bluetooth device. This temporary key encrypts the connection and maintains it for a short period of time. BLE bonding refers to the establishment of a long-term connection with another device. The devices would have exchanged long-term encryption keys and during the pairing process, these keys are utilised. Hence, the devices do not have to generate new encryption keys at the time of each connection.

  Bluetooth Security of IoT devices encompass multiple security modes and security levels. Security during the pairing and bonding processes includes three phases:

  • Phase 1 (Pairing) – Capability exchange
  • Phase 2 (Pairing) – Secure key generation
  • Phase 3 (Bonding) – Transport specific key distribution

  

 

Bluetooth Passkey Entry is a method to ensure that security risks are mitigated at the time of device pairing (Phase 2). However, this method has a few limitations. As of Bluetooth 4.2, the LE Secure Connections pairing process reduces most of the limitations involved in the pairing process using passkeys. Other methods for mitigating security risks while pairing are Numeric Comparison, Just Works and Out of Band Legacy pairing.

Wide Area Network (WAN) level security

WAN level security elements for an IoT gateway device include the following:

• Firewalls – An IoT firewall can be deployed in the network to protect the system against several security threats:
  • Network threats – The firewall is capable of preventing DDoS and application layer security breaches.
  • Abuse of service – IoT devices (including gateways) are protected from being used unexpectedly, without authorization.
  • Device threats – The firewall ensures that the devices in the IoT network are connected only with known and safe locations.

  Usually, the administrator of the network configures the firewall setting by defining the destination IP addresses, IP networks, destination protocols, ports or host/domain names that are permitted in the network.

• Port Lockdown – In each IoT device, disabling the open external ports can protect the hardware and the data within. Security attacks such as fuzzing, buffer overflow, DoS attacks, etc. can be prevented in this manner.
• Software-Defined Perimeter (SDP) Interface – Software-defined perimeter is a security framework that manages access to IoT resources based on identity. It works on the principle of hiding crucial assets within an opaque cloud that is inaccessible to outsiders. The hidden assets may also be on premises, in a perimeter network, data center server or an application server. The SDP interface acts as a broker between the protected applications and users who are allowed access on fulfilling the validation criteria. Essentially, SDP forms an invisible screen that protects IoT components against cyberattacks, malware and other such security breaches.

WAN level security can also be ascertained in several other ways. This includes maintaining Access control lists and Blacklisting/Whitelisting MAC addresses.

Summary

Now we have a fair idea of the various measures one can take to secure the gateway device in an IoT infrastructure. In the next part of this blog series, we explore the cloud and application security aspects along with communication security.

Other articles in this blog series:

IoT Security – Part 1 of 3: Principles of Holistic Security and End Point Security Elements
IoT Security – Part 3 of 3: IoT Cloud and Application Security

IoT Security – Part 1 of 3: Principles of Holistic Security and End Point Security Elements

The emergence of the Internet of Things (IoT) has revolutionized the way in which businesses operate in the new industrial era. IoT is at the helm of rapid growth, with the global market for IoT end-user solutions predicted to reach 1.6 trillion US dollars by 2025.

In this context, the topic of IoT security is of great interest to product designers, manufacturers and procurement personnel across industries. As the number of connected devices grows, the volume of data to be protected and complexity of IoT security also increases.

How can you secure your Internet of Things ecosystem to be immune to severe security breaches? – This is the question being enthusiastically discussed in the industry circles today. Our in-house IoT experts believe that a holistic approach to IoT security is the way forward.

This is the first in a three-part series of blogs that discusses the holistic security approach and ways in which full-stack IoT security can be achieved.

Full Stack IoT Cybersecurity

When developing a secure end-to-end IoT ecosystem, it is crucial to ensure that security protocols are adhered to at each layer of the infrastructure. In the image below, we have highlighted the various layers of a full-stack IoT solution:

• The end-user application layer
• IoT cloud framework
• IoT gateway layer
• Devices with IoT sensors
• IoT connectivity (PAN/WAN)

IoT holistic security should encompass methodologies to ensure:

1. End Point Security at the level of the Device Sensor
2. Gateway Security that constitutes Edge Routing
3. Cloud and Application Security
4. PAN and WAN Communication Security at the connectivity level

End Point Security Elements

End point security encompasses all the protocols that should be followed to ensure that there are no security violations at the IoT device level. The primary areas of focus are security at:

• Device hardware/software level
• Bluetooth PAN level

Device hardware/software security – IoT device manufacturers have been increasingly incorporating security features in the device hardware and software to offer a primary layer of protection.

Key security features that can be integrated at this level include:

• Physical and Tamper Security – Each connected device in an IoT infrastructure can be a potential entry point to access the entire network or the confidential data handled within. For security to be completely realized in an IoT infrastructure, it should be incorporated in the devices during the design and build phases.

  The IoT devices should be able to authorize their identity, encrypt their data, and protect data that is stored locally.

  Physical security is an important aspect as well.

  • Devices should be designed to offer tamper resistance so that it is difficult to extract sensitive information by unauthorized personnel.
  • Devices can be located in unattended or private areas to limit physical access. Chips that manage crucial functionalities of a device can be removed by attackers. To prevent this, these chips can be configured in a way that they get destroyed during the unauthorized removal process.
  • Special attention should also be given to the device casing. As a safety measure, it is possible to program the device to get permanently disabled on opening the case by unauthorized personnel.
• Secure Boot and Root of Trust – A hardware Root of Trust is the security foundation for an SoC, electronic system or any other semiconductor device. It consists of the keys for cryptographic functions.

  Hardware Root of Trust can be categorized into fixed function and programmable categories.

  • Fixed function – A fixed function root of trust is a simple and small state machine that performs few static functions like certificate validation, data encryption, key management, etc.
  • Programmable – A programmable root of trust has a CPU that performs all the functions of the fixed function root of trust and many more complex security functions. Since it is upgradable, it can be programmed to execute new cryptographic algorithms that protect from the dynamic and ever-evolving threat landscape.

  Root of Trust also enables the secure boot process of the device. Secure Boot is a mechanism that uses public key cryptography to ensure that the software components have been digitally signed and unmodified while the system boots.

  Root of Trust is based on a hardware-validated process of booting. When we combine this with the Secure Boot process that validates software integrity, the security loopholes that can be exploited are not easily accessible to hackers.

• ASLR – Address Space Layout Randomization (ASLR) is a memory protection technique for operating systems that uses randomization for avoiding attacks related to memory corruption, code injection, code reuse and buffer overflow.
• Guard Band in OS – A guard band offers insulation between signals in wireless data communication and is hence, effective in preventing interferences.
• Chip Security – A strong IoT security architecture begins at the chip level. The basic assets of a chip include cryptographic keys that safeguard data and authenticate devices in the network. Chip manufacturers have been introducing advanced security functions in chips that can form the foundation of secure IoT devices.
• TPM/HSM – Trusted Platform Module (TPM) is a hardware security solution that provides isolation of private keys. It also enables secure generation of cryptographic keys and random number generation. A Hardware Security Module (HSM) is a physically separate chip (in the form of a plug-in card or external device) that safeguards digital keys for crypto processing and authentication. HSM is also a more cost-effective solution when compared to TSM.
• Disable Debug Access – Disabling the debug interface, enabling Flash Security and disabling FLASH Mass Erase prevent the unauthorized reverse engineering of code on an IoT device.

Bluetooth PAN level security – This includes the following security considerations:

• Device Authentication and Device Identity – When a large number of devices are connected to an IoT network, strong device authentication processes need to be in place. Each IoT device is assigned a unique identity that is evaluated when the device tries to connect to the server directly or through a gateway.
  Administrators also find the unique ID useful for tracking and managing devices throughout their life cycles.
• Beacon Shuffling – Bluetooth beacons are vulnerable to attack by malicious parties. If a hacker has access to your beacons’ Majors, Minors, UUIDs and MAC addresses, your devices can be easily spoofed. The IoT infrastructure would then consider the clones as authorized devices.

  Beacon shuffling is a great way to prevent a cloning attack. Shuffling the identifiers on a daily or weekly basis modifies the Majors and Minors of the beacons randomly, and hence, prevents device spoofing.

Apart from the above measures, optimizing radio strength and disabling unused protocols in the Bluetooth stack can also help in reinforcing Bluetooth PAN level security.

Summary

We now have an idea of the various measures that can be implemented to ensure security at the IoT device (hardware and software) level and the Bluetooth PAN level. We will deep dive into Gateway security in Part 2 of this blog series. Stay tuned!

Other articles in this blog series:
IoT Security – Part 2 of 3: Analysis of Gateway Security in an IoT Infrastructure
IoT Security – Part 3 of 3: IoT Cloud and Application Security

FlexRay Protocol and the Modern ECU Network Architecture: An Insider’s Perspective

As the concept of safety-critical automotive systems came into prominence, traditional ECU communication protocols such as CAN were found to be insufficient. By no means can one doubt the efficiency of the CAN BUS system. However, certain requirements of safety critical components like ABS and Airbags could not be met by the typical CAN protocol. The primary reason for this inadequacy was the priority-driven bus arbitration system.

This system gives network access to a high priority message over a low priority message, also looking for the network access. The delay in the propagation of such messages had the potential to cause problems to a safety related automotive system. Therefore, the need for a protocol that could support multiple access using a time division approach, was felt. In order to counter the issue of delayed message delivery, FlexRay protocol was developed using the Time-Division Multiple Access (TDMA) technology.

Another use-case where the need for a protocol like FlexRay was felt is the X-by-wire technology. X can be anything from brake to steering to driving. And ‘by-wire’ implies replacing hydraulic system with the electro-mechanical system. High data transfer rate is the first pre-requisite of such systems and naturally, FlexRay was the preferred choice.

The two important keywords always associated with FlexRay protocol is fault-tolerance and determinism. While the TDMA technique ensures determinism or the consistency of data delivery to the nodes, fault-tolerance is achieved by dual-channel configuration of the FlexRay bus.

We will talk about all these aspects of FlexRay protocol and its impact in the subsequent sections. Keep reading!

What Makes FlexRay a Deterministic and Fault-Tolerant COM Protocol?

Before we discuss the deterministic and fault-tolerant qualities of FlexRay protocol, lets understand why these are so important.

Determinism implies that nothing happens by chance! In the context of an ECU network, the output must always be determined by the input, thus making the entire system a predictable one. In safety-critical applications like ADAS, cruise control, Air bags, etc. time determinism play a very crucial role. The data must arrive to the correct node in a predictable time-frame (in the tune of microseconds), so that the required functions are carried out in real-time.

Now that we understand the importance of determinism, let’s explore how FlexRay protocol achieves it.

In a bus system with multiple nodes, only one node is able to write data to the bus at one instance. A contention occurs if two nodes are required to write data at the same time. Communication protocols mitigate this issue by using several schemes. For instance, CAN uses arbitration where high priority marked nodes get to write the data first. While it does the work, such a scheme does not guarantee timely delivery of data and also does not allow higher speeds.

FlexRay protocol achieves determinism by the virtue of being a time-triggered protocol. It manages the nodes on the network with a scheme called TDMA (Time Division Multiple Access). The FlexRay nodes do not have an uncontrolled access to the bus. Instead, the nodes need to be synchronized as per a communication schedule. Each FlexRay message is assigned a specific time-slot that ensures that every node awaits its turn for writing data to the bus. The configuration of the FlexRay nodes assumes much importance here, as each node must be configured with the correct network parameter before they are added to the network. As various stakeholders and cross-functional teams are involved in the development process, a standardized format to maintain network configuration parameters was also introduced along with FlexRay protocol. This standard is called FIBEX (Field Bus Exchange Format).

From network designers to testing engineers, every stakeholder shares the configuration parameters through FIBEX file so that uniformity is maintained. Such a scheme enables quick configuration of the FlexRay protocol stack, as well as ECU configuration and HIL Test system configuration for functional testing of the stack.

Along with time-determinism, another crucial feature of FlexRay protocol is fault-tolerance. Failing to deliver the data to the node constitutes a fault. For safety-critical applications, such a fault can cause disaster.

In order to minimize risk of failure, FlexRay has redundancy in place. With a dual channel network topology, FlexRay protocol defines Channel A and Channel B, where one of them works as a redundant channel. For safety-critical applications, the nodes connected to the bus can use both channels to transfer data. Over and above this, there are fault-tolerant mechanisms at the physical layer, interface layer and the protocol engine.

How FlexRay is Best Suited for X-By-Wire Systems

X-by-wire systems essentially substitute the mechanical component of the system with an electronic one. For instance, in a steer-by-wire system, the mechanical structure between the steering control and the wheels is replaced with an electronic system comprising distributed ECUs, sensors and actuators.

For such distributed systems to work efficiently, a deterministic and fault-tolerant protocol software is required and that is the reason why FlexRay has been proposed to be at the helm of data communication in such systems.

A snapshot of features that make FlexRay the preferred protocol for X-by-wire applications:

1. Redundant communication channels, a pre-requisite for such applications
2. Time triggered communication system that ensures time-determinism
3. Faster data transfer rate up to 10 Mbps
4. High-performance, collision free data transfer

Is FlexRay here to Replace CAN and LIN?

CAN and LIN protocols have been the backbone of automotive ECU communication for a really long time. The architecture built around these protocols have also evolved to be mature and robust. Automotive applications like Body Control Modules, Powertrain and Seating Control still rely on these protocols.

The inclusion of FlexRay protocol, at least for now, is limited to the applications that require deterministic and fault-tolerant communication of data. In ADAS and X-by-wire systems where timely and fast delivery of data from a multitude of sensors is paramount, FlexRay comes across as the most reliable protocol.

The trend in the automotive industry is about embracing a hybrid communication architecture.. The FlexRay protocol could be used for high-speed communications and CAN/LIN for the regular applications like Body Electronics, Powertrain, etc. In a hybrid communication ecosystem, gateways can take care of the compatibility of messages sent across different protocols. FlexRay being a dual-channel protocol, entails a higher cost than LIN and CAN bus systems. In order to optimize cost, the hybrid protocol approach works perfectly fine and is also being adopted by the OEMs globally.

Conclusion

The next generation of automobiles will have codes running all over the vehicle and controlling components using a plethora of sensors and actuators. FlexRay, along with several other such technologies, are proving to be much-needed catalysts for such innovations. With safety emerging as one of the mandatory attributes of a vehicle, FlexRay protocol may one day become the de-facto ECU communication protocol.