With the growth of connected Internet of Things (IoT) applications, embedded developers face additional validation requirements. Device security, timing behaviour, and energy efficiency are new topics that need careful implementation and validation. This blog gives you an overview and explains how Arm software components and development tools helps the industry to:
Security is essential for connected IoT devices as they frequently require access control and encrypted communication. Verification of security is a new challenge in the embedded industry as usually "embedded" meant that no one could access the system and thus it was considered as secure.
As security is an industry wide problem and fragmented solutions are difficult to use and can lead to poor system security Arm initiated the Platform Security Architecture (PSA). The PSA is a holistic set of threat models, security analyses, hardware and firmware architecture specifications, and an open source firmware reference implementation. The PSA provides a recipe, based on industry best practice, that allows security to be consistently designed in, at both a hardware and firmware level. This helps embedded developers to get their designs securely deployed in the field faster.
The PSA Developer APIs provide a high-level interface for software developers who want to use the security functions of the PSA Root of Trust (PSA-RoT). This interface masks underlying hardware differences and provides a consistent developer experience across system-on-chips (SoCs) and platforms. These APIs are used by RTOS vendors and software developers to enable Crypto Services, Attestation Services, and Secure Storage Services. Security experts use the PSA Firmware Framework APIs for making custom secure functions.
PSA Functional API Certification checks the implementation of the PSA Developer APIs. To help accelerate industry adoption of the PSA Developer APIs, an open source reference implementation is provided as part of the Trusted Firmware-M project. The corresponding API test suite creates a report for Crypto, Secure Storage and Attestation. These test results give confidence on the system security implementation and are the fundamental for the PSA Certified program.
Another requirement for embedded systems, the validation of worst-case execution timing is often hard to verify as very small microcontrollers lack required debug features. New approaches to timing verification and execution profiling can help to overcome these obstacles.
System Analyzer - part of the µVision debugger - shows exceptions, correlated to thread events of your real-time operating system (RTOS):
Arm's Event Recorder is based on annotations in your system on critical execution points. The events can be filtered and the ones you are interested in are recorder in an event buffer. Every event is time stamped along with other information that is formatted by a debugger using an XML description file – this keeps the software overhead in the embedded system down to a minimum. Compared to printf debug style, an event is recorded in less than one microsecond. Events that are filtered out take just a few CPU cycles. Arm Keil MDK is using this technology to provide RTOS kernel awareness and to enable analysis of the MDK-Middleware components for the developer. But it is also easily applied to user code:
Using Event Statistics, you can record minimum and maximum execution times of your application. The µVision debugger shows the timing statistics and also records which calls cause minimum and maximum timing.
Finally, IoT end nodes need to be power efficient, as they often run on batteries that should last long without the need for service or maintenance. Often, a single misconfigured interface increases power consumption dramatically. But finding the reason for the misconfiguration is a difficult task. In combination with ULINKplus, Event Statistics help you to identify code that is consuming too much power. The power measurement readings of ULINKplus are fully integrated into System Analyzer. With this, you can identify hardware and software problems, down to GPIOs that have the wrong pull-up value: