Security versus functional safety: a view from the Processor Software Development Kit


What is the difference between security and functional safety?

At its core, the difference between security and functional safety can be summed up in one word – intent. Security protects against threats from malicious intent. Functional safety on the other hand protects against hazards from malfunction, the cause (or intent) of which may or may not be malicious. As an example, consider an industrial motor drive. Preventing the drive from supplying torque-generating energy and restarting unexpectedly is a safety function. If this same drive can be controlled remotely, sending data and receiving commands over the network, enabling only authenticated access to the drive is an example of a security feature.

So what is common between the two?

The goal of both, functional safety and security is that system integrity is preserved in the face of the hazard or threat, no matter whether the source is malicious intent or malfunction.  What this means is minimizing the likelihood of unacceptable risk from the hazard or threat to assets or human life. Since functional safety and security have the common goal of avoiding or mitigating impact from hazards and threats, there can be overlaps in the mechanisms used to achieving this goal.

System integrity as it applies to security

To prevent system integrity from being compromised, you need to be able to monitor and control the software that runs on a system via some kind of approval mechanism. This mechanism should check the software running has not been altered (intentionally or unintentionally) between "there" and "here," or between "then" and "now". This is integrity as it applies to security.

To prevent system integrity from being compromised, we also need to verify that the source of the software is trusted (i.e. you are who you say you are). This is authentication, as it applies to security.

Although crucial building blocks, integrity and authentication are just some of the security features a system may need. Access control, confidentiality, availability and non-repudiation are other crucial security features.

System integrity as it applies to functional safety

Functional safety standards mandate following a rigorous software development process. This process includes traceability from the software product specification through final test and validation. Developing software targeting functional safety standards requires multiple cross functional reviews such as failure mode analysis and design reviews and analysis. Hardware and software diagnostics testing is deployed to detect faults during system operation.

To summarize, the process of quantifying risk from hazards or threats and then deploying techniques to mitigate impact from them is the common goal that drives the development of a system with security and functional safety features.


Texas Instruments’ Processor SDK portfolio of devices supports a host of security features as part of both Linux and TI-RTOS operating systems, and is available today via TI’s software portal.

TI’s next generation AM6x device family will support both functional safety and security features in hardware and software. Typical functional safety features of this device include cluster separation, hardware and software diagnostics and a dual-core lock step cortex R5F. Functional safety features target automotive and industry standards ISO 262621 and IEC 615082. Typical security features include whitelist firewalls, debug security, cryptographic acceleration, initial secure programming, secure boot and runtime security.

The AM654x family coupled with the Processor SDK portfolio leverage decades of TI’s expertise in the areas of security and functional safety. With automation and cloud-based communication becoming commonplace in applications, these devices are designed keeping in mind the systems of the future.

References and further reading: