Jeff Shepard

Quantum compasses and optical imaging for global positioning and navigation

October 27, 2020 By Jeff Shepard Leave a Comment

There is an emerging demand for a replacement for today’s global navigation satellite systems (GNSS), and especially for the global position system (GPS) in the U.S. Part one of this three-part FAQ series presented several of the shortcomings of today’s GPS technology and some efforts to augment it and improve its performance. Part two presented a terrestrial-based technology that is already being offered as a substitute for GPS in many applications. This third and final installment looks into the future at possible quantum-based and optical-based position, navigation, and timing (PNT) technologies that could eliminate the need for GPS devices.

Close-up of a quantum accelerometer (Image: Imperial College London)

The next generation of inertial sensors may be based on a compact gyroscope and a three-axis accelerometer using new techniques in atom interferometry. Called a quantum compass, it is an instrument that measures relative position using the technique of atom interferometry. It includes an ensemble of accelerometers and gyroscope based on quantum technology to form an inertial navigation unit.

A quantum compass contains clouds of atoms frozen using lasers. By measuring the movement of these frozen particles over precise periods of time, the device’s motion can be calculated. The device would then provide a tamper-proof accurate position in circumstances where satellite navigation is not possible.

The ultimate goal is to build a new autonomous device that can compete with technologies based on global positioning systems without external communication drawbacks for recalibration. The device would then provide a tamper-proof accurate position in circumstances where satellites are not available for satellite navigation, e.g., a fully submerged submarine.

AIG’s (atomic interferometer gyroscopes) and ASGs (atomic spin gyroscopes) use an atomic interferometer to sense rotation or, in the latter case, uses atomic spin to sense rotation with both having a compact size, high precision, and the possibility of being made on a chip-scale. AIGs may compete, along with ASGs, with the established ring laser gyroscope, fiber optic gyroscope, and hemispherical resonator gyroscope in future inertial guidance applications.

The UK’s first quantum accelerometer for navigation has been demonstrated by a team from Imperial College London and M Squared. M Squared developed a universal laser system for cold atom-based sensors that the company has already implemented in a quantum gravimeter. That laser is now also used in the quantum accelerometer built in collaboration with Imperial. Combining high power, exceptionally low noise, and frequency tunability, the laser system cools the atoms and provides the optical ruler for the acceleration measurements.

The quantum accelerometer relies on the precision and accuracy possible by measuring properties of supercool atoms. At extremely low temperatures, the atoms behave in a ‘quantum’ way, acting like both matter and waves. The current system is designed for the navigation of large vehicles, such as ships and submarines. Smaller systems are envisioned in the future.

In France, the joint laboratory iXAtom brings together the knowledge of the French company iXblue — experts in optical gyroscopes, photonics, and inertial navigation — and personnel from LP2N specialized in atom interferometry. This collaboration aims to make technological advances using cold atoms to develop the next generation of inertial sensors for industrial, military, and Space applications, with anticipated improvements in their performance.

Cold-atom quantum accelerometer simplified schematic (Image: iXAtom)

In the near future, iXAtom plans to develop a compact gyroscope and a three-axis accelerometer based on new techniques in atom interferometry. The ultimate goal of iXAtom is to build a new autonomous device that can compete with technologies based on global positioning systems without the drawback of external communication for recalibration.

Optical navigation using terrestrial objects

Optical navigation using terrestrial landmarks and mapping has been under development for many years. Terrain Contour Matching, or TERCOM, was a navigation system used primarily by early versions of cruise missiles. It uses a pre-recorded contour map of the terrain compared with measurements made during flight by an on-board radar altimeter. A TERCOM system considerably increases the accuracy of a missile compared with inertial navigation systems (INS). The increased accuracy allows a TERCOM-equipped missile to fly closer to obstacles and generally lower altitudes, making it harder to detect by ground radar.

The limited data storage and computing systems of the time meant that the entire route had to be pre-planned, including its launch point. If the missile was launched from an unexpected location or flew too far off-course, it would never fly over the features included in the maps and would become lost.

DSMAC was an early form of artificial intelligence (AI) that could guide missiles in real-time by using camera inputs to determine location. DSMAC was used in Tomahawk Block II onward and proved itself successfully during the first Gulf War. The system worked by comparing camera inputs during the flight to maps computed from spy satellite images. The DSMAC AI system computed contrast maps of images, combined in a buffer, and then averaged. It then compared the averages to stored maps computed beforehand by a large mainframe computer, which converted spy satellite pictures to simulate what routes and targets would look like from a low level.

DSMAC automatic target recognition (ATR) machine learning (ML) flow chart. (Image: Wikipedia)

An example of a detection algorithm is shown in the flowchart above. This method uses M blocks of data, extracts the desired features from each then models them using a Gaussian mixture model (GMM). After a model is obtained using the data collected, conditional probability is formed for each target in the training database. This method can distinguish between vehicle types (wheeled vs. tracked vehicles, for example).

Since the data was not identical and would change by season and from other unexpected changes and visual effects, the DSMAC system within the missiles had to compare and determine if maps were the same, regardless of changes. It could successfully filter out differences in maps and use the remaining map data to determine its location. Due to its ability to visually identify targets instead of simply attacking estimated coordinates, its accuracy exceeded GPS guided weapons during the first Gulf War.

ImageNav™, developed by Scientific Systems for the US Air Force, is a modern optical navigation system for aircraft. ImageNav is a non-GPS precision navigation software that uses inertial navigation system information to match onboard camera imagery, including electro-optical and infra-red, against stored geo-registered digital terrain elevation data (DTED) to determine the precise location of an air vehicle in flight. It has a terrain database of the area being navigated and matches it with input from video cameras to work out its location.

ImageNav software is multi-threaded and scalable to run on multiple cores. ImageNav uses time-synchronized camera imagery and can accept PGM or PNG images up to 1024×1024 pixels in size and at up to 30 frames per second. ImageNav has been successfully tested on a number of aircraft but could also find uses in self-driving vehicles.

High Tech Celestial Navigation

Mariners have used various celestial navigation techniques since ancient times. Two stars, the local altitude, and a clock are all that’s needed to determine a position using a sextant. Celestial navigation can be surprisingly accurate; if the values are determined to within 1 arc minute, the possible error is about 1 nautical mile, but if the values can be determined to within 1 arc second, the possible error drops to about 30 meters. Today’s advanced optics and high-speed microelectronics can enable celestial navigation with an accuracy of 15 meters, without the need to know the altitude, even in a moving aircraft or missile.

Tracking fast-moving satellites like the International Space Station has helped to improve the accuracy of celestial navigation. Having large numbers of fast-moving objects to get bearings on means that the system, called Skymark, can achieve greater accuracy than slow-moving stars. Skymark uses a database of visible satellites – both working satellites and space junk – and has a claimed accuracy of 15m (49ft), making it almost as good as GPS. And it uses a proprietary stellar horizon refraction algorithm that eliminates the need for a local vertical. Its accuracy depends on knowledge of the atmospheric density profile to provide a refraction estimation that replaces the vertical measurement in earlier celestial navigation systems.

Skymark can correct an emerging problem common to inertial navigation systems when access to GPS is denied: they tend to drift and lose accuracy over time, making them inadequate on their own for long-distance navigation. Skymark provides a system position fix through a unique combination of advanced optics, sensors, and algorithms to triangulate off of known positions of stars and satellites.

Today’s GPS is several decades old. It has received numerous upgrades, and completely new third-generation satellites are currently being launched. However, there’s growing concern that the system may be reaching the limits of its usefulness. To learn more about the limitations of GPS and what is being done to address those limitations, you might enjoy reading part one of this FAQ series, “GPS is a ubiquitous and problematic technology,” and part two, “eLORAN a terrestrial alternative to GPS.”

References:

Automatic target recognition, Wikipedia
ImageNav, Scientific Systems
iXAtom – LP2N and iXblue Cold Atoms joint laboratory, iXAtom
Quantum ‘compass’ could allow navigation without relying on satellites, M Squared
TERCOM, Wikipedia

eLORAN a terrestrial alternative to GPS

October 26, 2020 By Jeff Shepard Leave a Comment

Terrestrial-based hyperbolic navigation technologies predate today’s satellite-based global positioning system (GPS). Starting with developments in the 1930s and 1940s, land-based long-range navigation (LORAN) systems using hyperbolic navigation have been continuously advanced. Today, the enhanced LORAN (eLORAN) system has been offered a more secure alternative to GPS.

Hyperbolic navigation technologies were independently developed in the U.S. and the U.K during World War II. The Gee system was developed in the U.K. and used by the Royal Air Force. It measured the time delay between two radio signals to produce a location, with accuracy on the order of a few hundred meters at ranges up to about 350 miles (560 km). The first hyperbolic navigation system was to be used operationally, entering service with RAF Bomber Command in 1942.

Hyperbolic navigation example (Image: Wikipedia)

In the figure above, the three ground stations A, B, C, have known locations. The times it takes for a radio signal to travel from the stations to the receiver are unknown, but the time differences are known. That is, t_A, t_B, t_C is unknown, but t_A– t_B and t_A– t_C are known. Each time difference can be used to locate the receiver on a hyperbola branch focused on the ground stations. The receiver is then located at one of the two intersections. Other navigation information can be used to determine at which intersection the receiver is located.

Gee inspired the original LORAN system developed in the U.S. LORAN was similar to the Gee system. Still, it operated at lower frequencies to provide an improved range up to 1,500 miles (2,400 km) with an accuracy of tens of miles. It was first used for ship convoys crossing the Atlantic Ocean, and then by long-range patrol aircraft, but found its main use on the ships and aircraft operating in the Pacific theater during World War II.

Early LORAN equipment was expensive, limiting its use to military and large commercial users. With advanced electronics, system costs came down, and automated receivers became available. The third-generation called LORAN-C became available and offered a longer range and location accuracy of a few tens of feet. As a result of advances in microelectronics, LORAN-C receivers dropped significantly in price, and earlier generations of LORAN were mostly abandoned.

Hyperbolic navigation and the Decca system

The Decca system for hyperbolic navigation was invented in the U.S., but development was carried out in the UK. The Decca Navigator System was a hyperbolic radio navigation system that allowed ships and aircraft to determine their position by receiving radio signals from fixed navigational beacons. The system used a phase comparison of two low-frequency signals between 70 and 129 kHz, as opposed to pulse timing systems like Gee and LORAN. This made it much easier to implement the receivers using 1940s electronics.

And, unlike LORAN, Decca was not known to the Germans and thus free of jamming. After the war, it was extensively developed around the UK and later used in many areas worldwide. Decca’s primary use was for ship navigation in coastal waters, offering much better accuracy than the competing LORAN system. The opening of the more accurate Loran-C system to civilian use in 1974 offered stiff competition, but Decca was well established by this time and continued operations into the 1990s. Decca was eventually replaced, along with Loran and similar systems, by satellite-based GPS during the 1990s.

The display head, or “decometer bowl”, of a Decca Navigator Mk 12 (ca. 1962). Not shown is the much larger receiver unit. (Image: Wikipedia)

Enter enhanced LORAN

Enhanced LORAN (eLORAN) is the 21st-century evolution of LORAN-C, which was operational for over 60 years. A trusted positioning, navigation, and timing system initially developed during World War II, LORAN-C provided long-range and highly accurate wireless signals supporting navigation for aircraft and maritime applications globally. Improved over the last 20 years, eLORAN utilizes the same low frequency, high power radio signals transmitted from land-based towers. With reported accuracy as good as ± 8 meters, the system is competitive with unenhanced GPS. eLORAN also includes additional pulses which can transmit auxiliary data such as Differential GPS (DGPS) corrections, as well as ensure data integrity against spoofing.

A single tower provides users with a highly accurate timing signal, and with 3 towers “in view,” a user device can derive its 2D location (latitude and longitude). Transmitting at 90-110 kilohertz and operating on a digital channel, eLORAN exceeds the accuracy, availability, integrity, and continuity performance requirements for all modern PNT applications. eLORAN is difficult to spoof or jam, and it is nearly impossible to do so at a distance. Just as equipment required to spoof and jam GNSS and GPS must mimic relatively low powered transmissions, spoofing and jamming eLORAN requires very high-powered transmissions.

eLORAN is a high power, low-frequency, ground wave radio broadcast system capable of providing 10- to 20-meter positioning accuracy, Stratum-1 frequency distribution, and Universal Time Coordinated (UTC) timing well within 1μs across 1,000 miles or more. (Image: Continental Electronics)

eLORAN also utilizes differential corrections to improve accuracy over the LORAN-C system significantly. Much like Differential GPS/GNSS (DGPS/GNSS), differential monitoring reference stations can be deployed across the nation. These reference stations receive the raw eLORAN signals from the main transmitting towers, detect any deviations and send corrections back to the eLORAN towers. The eLORAN towers then transmit the corrections via the LORAN data channel (LDC) in the main eLORAN signal to all users, substantially improving PNT accuracy.

In addition to improving accuracy, the LDC brings a unique capability to all eLORAN customers: The ability to send one-way data communication signals for any customer need. These data commands can penetrate buildings, underground significantly, and underwater, providing a unique and powerful command and control capability.

eLORAN capabilities include:

The signal is 3-5 million times stronger than GPS/GNSS
999% reliability & availability
1,200-mile signal range
Transmitted at up to 1 MW of power and nearly impossible to disrupt, jam, or spoof
Spectrum: 90 kHz to 110 kHz internationally protected
Usable anywhere, penetrates all buildings, structures, tunnels, underground, underwater w/without amplification
Added encryption and authentication make eLORAN spoof-proof
Synchronized to Universal Coordinated Time (UTC)
Supports unmanned/autonomous operations (low cost)
Terrestrial, independent but interoperable with GPS/GNSS
Required infrastructure for US national coverage: 6 towers for timing, 19 for position & navigation
User antenna integrated with a receiver, no need for roof or external installations

Pentagon ordered to find GPS replacement

eLORAN is expected soon to have competition as a possible replacement for GPS. There are numerous efforts to develop the so-called “assured position, navigation, and timing” (APNT) systems. APNT systems are designed to compensate for any loss of GPS signals and provide multiple alternative sources of data that can validate existing GPS data’s trustworthiness.

As a result of the growing vulnerability of GPS to jamming and spoofing (for a discussion of GPS vulnerabilities, you can read part one of this FAQ series, “GPS is a ubiquitous and problematic technology”), the U.S. Senate Armed Services Committee (SASC) has ordered the Pentagon to provide an alternative to GPS within two years. In Section 1601 of the 2021 National Defense Authorization Act (NDAA), SASC states that the two-year deadline is “consistent with” urgent needs, and the Pentagon must:

Prioritize and rank order the mission elements, platforms, and weapons systems most critical for the operational plans of the combatant commands;
Mature, test, and produce for such prioritized mission elements sufficient equipment —
- to generate resilient and survivable alternative positioning, navigation, and timing signals; and
- to process resilient, survivable data provided by signals of opportunity and on-board sensor systems; and
Integrate and deploy such equipment into the prioritized operational systems, platforms, and weapons systems.

The third and final FAQ in this series, “Quantum compasses and optical imaging for global positioning and navigation,” will present several advanced technologies proposed as unhackable and unjammable GPS replacements for providing PNT.

Resources:

Decca Navigator System, Wikipedia
eLORAN, a Resilient Complement to GPS/GNSS, Hellen Systems
eLORAN transmission systems, Continental Electronics
Hyperbolic navigation, Wikipedia

GPS is a ubiquitous and problematic technology

October 25, 2020 By Jeff Shepard Leave a Comment

Much of the world depends upon satellite systems for precise navigation and timing services. The global positioning system (GPS) is a ubiquitous and problematic technology. Global navigation satellite system (GNSS) is the umbrella term for satellite navigation systems that provide autonomous geo-spatial positioning with global coverage. GNSS includes GPS, GLONASS, Galileo, Beidou, and other regional systems. A closely-related concept is a position, navigation, and timing (PNT) systems.

There are 31 satellites in the GPS constellation, 27 of which are in use at a given time, with the rest allocated as stand-bys. The additional satellites over 24 improve the precision of GPS receiver calculations by providing redundant measurements. With the increased number of satellites, the constellation was changed to a nonuniform arrangement. Such an arrangement was shown to improve accuracy and also improves reliability and availability of the system, relative to a uniform system when multiple satellites fail. With the expanded constellation, nine satellites are usually visible from any point on the ground at any one time, ensuring considerable redundancy over the minimum four satellites needed for a position.

A visual example of a 24 satellite GPS constellation in motion with the Earth rotating. Notice how the number of satellites in view from a given point on the Earth’s surface changes with time. The point in this example is in Golden, Colorado, USA (39.7469°N 105.2108°W). (Image: Wikipedia)

GPS/GNSS/PNT jamming, spoofing, and other forms of interference are growing in frequency and severity. And space-based systems are not immune to severe space weather or cyber-attack. According to a London School of Economics report, loss of satellite navigation for five days would cost the U.K. more than £5.1 billion. And according to the U.S. National Institute of Standards and Technology, failure of the GPS would cost the US economy $1 billion a day and up to $1.5 billion a day if it occurred during planting season for farmers. But GPS outages are surprisingly common.

As a result, there are numerous efforts underway to develop alternatives to today’s space-based technologies. This three-part FAQ series will first look at various failure modes for space-based GPS/GNSS/PNT systems and the U.S. and European programs to identify alternative technologies. Part two will look at existing terrestrial-based alternatives to GPS/GNSS/PNT satellites. Part three will look into the future at possible quantum-based and optical-based PNT technologies that could eliminate GPS devices’ needs.

Jamming, spoofing, meaconing, and other GPS failure modes

GPS vulnerabilities include unintentional interference such as radio frequency interference, ionospheric interference caused by solar activity, and intentional interference such as jamming, spoofing the system with counterfeit signals, and electromagnetic pulse (EMP) attacks on the satellites. There is currently only minimal protection against ionospheric interference caused by solar activity or EMP attacks by an enemy. A massive solar storm, similar to the Carrington Event of 1859, could knock out the entire GPS satellite network.

The signals sent out by the satellites are more vulnerable than the satellites themselves. Jamming is simple and inexpensive, with jamming devices costing under $200. While the jamming devices are illegal in many countries, including the U.S., they are made in large quantities in China and are readily available. The military regularly jams GPS in certain areas while testing equipment or during military exercises. The US Government also regularly performs tests and exercises that lead to disruption of the satellite signal.

Handheld GPS jammer that works against a variety of civilian GPS frequencies (L1 L2 L3 L4 L5), LoJack, and GLONASS (Image: Jammer Store)

But spoofing GPS signals may be a greater problem if a less frequent one. When the signal is jammed, the device stops working, which is apparent to the user. When the signal is spoofed with a counterfeit signal, the device “lies,” and the user is typically unaware of the spoof. Spoofing is more complex than jamming and requires the user to recreate the complex coarse acquisition (C/A) code. The C/A code rate is 1.023 million bits per second. Not only does each GPS satellite broadcast its own unique 1023 bit C/A code, but it also repeats its C/A code every millisecond. Spoofing can be implemented using widely available signal generators.

Meaconing is the interception and rebroadcast of navigation signals. Meaconing avoids the burden of implementing the generation of the complex GNSS signal structures and C/A codes and also causes the GNSS receiver to provide erroneous PNT information because the reception and re-broadcast process changes the relative delays of the GNSS signals as seen by the receiver, compared to the relative delays of the authentic GNSS signals at the receiver’s location. These signals are rebroadcast on the received frequency and with power higher than the original signal to confuse the target’s navigation. In some cases, the signal is initially rebroadcast exactly as received but then slowly changed over time to further deceive the receiver.

GPS III coming soon

The first most powerful Global Positioning System (GPS) satellite ever designed and built for the U.S. Air Force launched December 23, 2018. Lockheed Martin’s GPS III satellites will have three times better accuracy and up to eight times improved anti-jamming capabilities. Spacecraft life will extend to 15 years, 25 percent longer than the newest GPS satellites on-orbit today. GPS III’s new L1C civil signal will also make it the first GPS satellite broadcasting a compatible signal with other international global navigation satellite systems, like Galileo, improving civilian users’ connectivity.

GPS III satellite in orbit. (Image: Lockheed Martin)

Today, Lockheed Martin is under contract with options for up to 32 GPS III and GPS III Follow On (GPS IIIF) satellites. The final GPS III satellite is currently scheduled to be launched in 2023. GPS III satellites will be compatible with international global navigation satellite systems, allowing users to receive signals from any country’s satellites, maximizing their chances of receiving a strong and accurate signal, whether in a natural valley or an urban canyon. Perhaps most important, GPS III satellites will be harder to jam—either by accidental transmissions or by enemies. This gives military users more assured access to GPS.

As GPS III evolves, as part of the Air Force’s GPS IIIF acquisition, the satellite’s design will incorporate a new, fully digital navigation payload, an accuracy-enhancing Laser Retro-reflector Array, a Regional Military Protection (RMP) capability, and a government-furnished Search & Rescue payload.

European Space Agency seeks 5G enhancement to GPS.

The European Space Agency (ESA) has launched a call for proposals to demonstrate new 5G cellular networks’ capabilities to support positioning and timing applications to complement satellite navigation, just as today’s smartphones harness cellular data to support their positioning services.

5G will bring higher speed, larger traffic capacity, and ultra-low-latency (or signal delay) communications. But 5G will also usher in a range of new possibilities for positioning, navigation, and timing (PNT).

The 5G networks will allow new types of measurements made possible by advanced antennas and new positioning signals at higher frequencies, at both base stations and the user receivers. 5G networks will also bring enhanced connectivity to improve cloud-based positioning applications and value-added services. While satellite navigation works optimally in outdoor environments with a wide view of the sky, 5G PNT has the potential to bring PNT to deep ‘urban canyons’ in high-rise city centers and even indoor warehouses, wherever 5G networks are deployed.

The combination of satellite navigation and 5G brings the promise of high performance, secure, and resilient PNT services and a seamless application of PNT applications from outdoor to indoor environments and from rural to urban areas.

With ESA’s new call for ideas, the Agency is inviting proposals to implement pilot projects to demonstrate the viability of 5G PNT solutions in a number of use cases:

Indoor PNT for ‘Industry 4.0’, as needed to support the operations of smart warehouses and factories or smart city applications requiring transition from indoor to outdoor environments.
Outdoor applications where a robust back-up to satellite navigation is essential to meet safety requirements, such as autonomous driving or drone navigation
Applications where robust time and frequency synchronization are necessary, both in outdoor and indoor environments, like smart energy grids or the 5G networks themselves.

As shown, there are multiple efforts underway to improve today’s GNSS and GPS systems’ operation. But there is also general dissatisfaction with the existing systems, and there are efforts underway to develop completely new alternatives. Part two of this FAQ series will look at existing terrestrial-based alternatives to GPS/GNSS/PNT satellites. Part three will look into the future at possible quantum-based and optical-based PNT technologies that could eliminate the need for GPS devices.

References:

Economic Benefits of the Global Positioning System (GPS), National Institute of Standards and Technology
Economic impact to the UK of a disruption to GNSS, London School of Economics
ESA call to demonstrate positioning and timing capabilities of coming 5G networks, European Space Agency
Global Positioning System, Wikipedia
GPS III, Lockheed Martin

Functional safety for embedded systems – Virtual Roundtable (part 2 of 2)

October 23, 2020 By Jeff Shepard Leave a Comment

Hosted by Jeff Shepard, EE World has organized this “virtual roundtable” into “Functional Safety for Embedded Systems.” Panelists include Anders Holmberg (AH), General Manager Embedded Development Tools with IAR Systems, Mike Dow (MD), Senior Product Manager, IoT Security with Silicon Labs, Jim McElroy (JM), VP of sales and marketing at LDRA Technology, Dave Hughes (DH), founder and CEO of HCC Embedded

JS: What is the least understood aspect of designing functional safety in embedded systems and devices?

DH: In my opinion, there is far too much focus on static and dynamic analysis as the “be all and end all” of functional safety. These are just small parts of any functional safety-development process. By far, the most important thing is traceability. This is the glue the binds the whole rationale for the safety case together. From requirements, through design and implementation to test cases, the completeness of the traceability is what enables you to make a safety case.

Dave Hughes (DH), founder and CEO of HCC Embedded

JM: Least understood—the concept that functional safety is about designing automated safety and protection mechanisms that operate properly when the systems themselves may be operating in a degraded mode due to device or system failure or deliberate attack. Developing functionally safe systems requires solid programming practices as well as a different “protection-based” mindset. From there, developers also need to understand that functional safety is required at all levels—hardware, firmware, and software. With software, functional safety requires an auditable, traceable process, automated static and dynamic analysis, and measurable and adequate unit- and system-level testing.

MD: The biggest misunderstandings seem to be around standards that need to be followed for different equipment types. For home appliances, the main standard that must be complied with is the IEC 60730 – Automatic Electrical Controls, and for most other equipment, IEC 61508 with Safety Integrity Ratings (SIL) are used.

JS: Is it necessary, better, or more efficient to use a coding standard such as MISRA C or MISRA C++ compared with an in-house developed standard to meet functional safety requirements?

AH: The various safety standards essentially mandate that you use a coding standard to reduce the complexity and ambiguity inherent in the C/C++ languages. Developing such a safe, secure, and maintainable coding standard from scratch is not something you typically do, as it requires extremely good knowledge of all the murkier corners of the language standards. The latest MISRA revisions are well thought out, field-proven, and strikes a balance between rigor and usability. So adopting MISRA as a base for a coding standard is a good first step.

Jim McElroy (JM), VP of sales and marketing at LDRA Technology

However, a standard like MISRA that deals only with language features does not cover other aspects of how you write and organize your code. So the safety standards advise you to cover such items in your own complementary coding standard. Such a standard can include things like rules for using and abusing global variables, including how to properly use the ‘volatile’ keyword, naming conventions, how you partition your code into modules, version control hygiene, etc.

The thing with a coding standard like this is not to always follow it to the letter, but to set you up with a thought-out system for how you should work. Deviations are always possible, as long as you do so consciously, with a clear purpose, and document what you do.

And your guidelines should have a section on how to deal with and sign off deviations.

JM: Some of the industry’s best minds have worked together to create off-the-shelf coding standards such as MISRA C and MISRA C++ that address best programming practices to help ensure the development of safe and secure software. These standards serve as readily available best practices supported by industry-proven tools to ensure coding standards compliance. Efficiency is most certainly improved by leveraging COTS tools and commercial standards. Most assuredly, leveraging these standards will result in higher quality code and are therefore better than no standard at all. That said, depending on the application, the MISRA standard also enables deviation with justification, supporting the concept that the standard itself can be tailored based on the specific need of the application. As well, companies develop In-house standards to address their needs and the applications they produce. A best practice: leverage industry available standards, and as necessary, integrate rules from the in-house standard without deprecating the intent of the commercial standard without justification.

Mike Dow, (MD) Senior Product Manager, IoT Security with Silicon Labs

MD: I would say that if you don’t already have a coding methodology that is geared around producing functionally safe code, I would use MISRA or other similar functional safety coding standards. At least you know those methodologies have gone through a great deal of vetting. If you code on your own, the odds of you getting it right the first time or even the 20th time are slim.

DH: First, the specifics of the coding language used are a tiny part of any attempt to achieve functional safety. You only need to check how much of any particular safety standard is devoted to this subject to realize this. Coding should be a fairly mechanical step in implementing what has been designed and should be done using a language suitable for the task. MISRA C or C++ are options, but in my opinion, MISRA C is unnecessarily complex for functional safety use cases. Simplicity is a big factor in achieving functional safety and keeping the cost of the development down. This is a big subject, but as a taster, try to take a few hundred lines of MISRA-compliant C code validated by one tool and see what happens when you try to use another validation tool. It should not be so complex. It makes these projects far more expensive than they should be.

JS: How can developers improve functional safety testing methodologies when developing embedded systems?

AH: The safety standard in themselves has a bit to say on this topic, so reading up on what the selected standard discusses and recommends for testing and verification and cherry-picking the bits and pieces that make sense for you and your stakeholders is a very good start. In the space and aviation industry, there’s the saying “test what you fly – fly what you test”. This can be interpreted in many ways, but one takeaway is to be rigorous with how and what you test. Always make sure that what you are shipping is exactly what you tested. Establish testing practices early on and make sure that the system-level test is done on code built in exactly the same way as you build the release.

Read up on the ecosystem for testing-tools and associated hardware and consider investing in tools that make sense for your problem domain. It might feel like a big burden to adopt new tooling, but if it helps you identify just a small number of otherwise hard to find issues, the time and investment will pay off.

Further, just because you have a golden build configuration that you always test does not mean that you cannot build and test totally different configurations to try to provoke your code to fall over. A simple example can be to force the stack size to be so small that you are likely to provoke a stack overrun, to make sure you handle that gracefully. Another can be to build your code with maximum optimization and no optimization. If your tests behave differently, like missing a deadline when the code is not optimized, you have pinpointed an issue that should be on your radar going forward.

Anders Holmberg (AH), General Manager Embedded Development Tools with IAR Systems

DH: Embedded systems developers should not improve functional safety testing methodologies. A developer’s job is to follow the safety development process in the development plan using the methodologies specified in the plan. The functional safety development plan should assess what testing methodologies are suitable for the level of safety required and specify these.

JM: To improve functional safety testing methodologies, developers should leverage automation for requirements traceability to functional safety and security standards, static and dynamic analysis, as well as unit and system testing. Today, more organizations, even in the embedded space, are considering methodologies that use continuous integration/continuous deployment for more rapid development, testing, and deployment. In practice, automation techniques are used to help them develop high-quality code faster, measure the quality of that code, and integrate it with the rest of the system.

MD: The most important thing developers can do to improve testing methodologies is a document, train, and audit your processes for tool usage and test procedures.

JS: What is the most important feature designers should look for in an integrated development environment as it relates to functional safety and security?

JM: Developers leveraging an integrated development environment for functional safety, and security must have the ability to automate and demonstrate a completely traceable and auditable workflow. This workflow must go from requirements through verification and deployment that is compliant with industry-defined functional safety and security standards.

DH: Tools specification is part of the functional safety project planning. Tools should be selected based on whether they can meet the safety requirements of that plan, and different safety standards have different ways of assessing their suitability. IDEs are one of the tools that must be assessed within this framework.

AH: When selecting a toolchain and IDE for use in safety-critical projects, it can be beneficial to look for tools that are certified for your standard and integrity level. You can select a non-certified tool, but the work to justify that selection in compliance with the standard is rather big, is typically not re-usable in your next project, and requires a skill set that is a bit different from software design and coding.

An IDE that is easy to integrate with static analysis checkers and dynamic testing tools, or have such tools built-in, will always be easier to work with in the long run. Similarly, a well-integrated and feature-rich debugger will most likely ease the pain when you need to untangle a thorny problem.

JS: Thanks to our panelists for sharing their insights and experience! You might also be interested in reading “Security for Embedded Systems” – Virtual Roundtable (part 1 of 2).

Security for embedded systems – Virtual Roundtable (part 1 of 2)

October 22, 2020 By Jeff Shepard Leave a Comment

Hosted by Jeff Shepard, EE World has organized this “virtual roundtable” into “Security for Embedded Systems” Panelists include Haydn Povey (HP), General Manager Embedded Security Solutions with IAR Systems, Mike Dow (MD), Senior Product Manager, IoT Security with Silicon Labs, Jim McElroy (JM), VP of sales and marketing at LDRA Technology, and Dave Hughes (DH), founder and CEO of HCC Embedded.

JS: What is the most challenging learning curve for embedded developers when first starting to implement security features?

Haydn Povey (HP), General Manager Embedded Security Solutions with IAR Systems

HP: The most challenging aspect of implementing security is to understand what you are protecting, who you are protecting it from, and the value of the asset or impact an attack may induce. These are very difficult questions for any organization to answer, especially the potential impact, as there are relatively few reference points. For example, the need to protect Operational Technology (OT) against malware was seen as a relatively low priority for organizations until the recent spate of attacks, many of which have had an impact of tens of millions of dollars. The way to step over this learning curve is to adopt a standard, such as the EN 606345 for Consumer Electronics or the IEC 62443 for industrial and smart city applications. These standards outline the basic requirements for security, such as ensuring no fixed passwords and the move to proper cryptographic identity; the need to disclose vulnerabilities which requires proper versions management and code signature; and the need to enable updates into every device, with a formal secure boot process enabling a solid foundation that the device can trust whilst remediating. There are many other requirements, such as secured communications, but these become substantially easier to implement once the device has solid secure foundations.

MD: Typically, the most challenging aspect for developers new to security is gaining a good understanding of security basics. Security is like any other technology; you must understand the technology fundamentals before you can implement it. I think many engineers get hung up on the math of cryptography, and it spooks them. If they can start thinking as a system engineer and visualize the algorithms as a black box with function with inputs and outputs, it simplifies the process and makes the basic concepts easier to grasp. The truth is that if you don’t know the difference between asymmetric and symmetric cryptography – or what a hash function is good for – you will be overwhelmed and less likely to implement security at all or poorly if you do.

JM: For embedded software developers, the most challenging learning curve may center on understanding the scope of where security needs to be considered secure hardware, secure communication protocols, secure operating systems, secure boot, encryption, secure data at rest and in transit, secure coding practices to eliminate security vulnerabilities, robustness testing, etc. The list of considerations is large, and often the cost of developing a robust and secure embedded system becomes a major consideration. Decisions get made based on the anticipated “risk” of the system being exploited.

DH: All embedded development is challenging. Security requirements add to the challenge, and the degree of that challenge is determined by the target system’s specific security requirements. The jumping-off point is a detailed assessment of the risks from which you build, mitigating each risk while always keeping in mind that complexity obfuscates.

JS: What is the simplest thing designers can do to enhance embedded systems and devices’ security?

DH: Designers need to create a proper assessment of the risks their device should defend itself against. This is the core of building any security case and ensuring the resulting design is focused on what is actually required by the product without introducing unnecessary complexity. Reduce your attack surface!

JM: The simplest thing designers can do is apply automated static analysis, leveraging the latest secure coding standards like MISRA and CERT. This helps ensure secure coding practices and eliminate security vulnerabilities. For embedded software, best practices recognize that security needs to be considered from the beginning. It’s neither cost-effective nor functionally effective to bolt on security after the system has been built. Secure coding practices need to be applied, checked, and standardized across an organization. The simplest and most cost-effective way to accomplish this is by automating standards compliance, which also significantly enhances the embedded system’s overall security.

MD: Lock the debug port before you ship the product. It sounds simple, but you would be amazed how many times that is not done. The next most basic task is to have a secure boot based on an immutable root of trust. A secure boot is one of the most effective tools against all kinds of attack vectors.

HP: The simplest thing designers can do is to use the right tools. There are many nuances and challenges in the implementation of security, and no one expects every engineer to become a cryptography expert. Using the right tools can transition security from a complex engineering challenge to something every organization can implement. Similarly, there is a need to engage with the designers’ CISO team. Aspects such as product identity, vulnerability disclosure, and patching methodologies are all technologies the CISO works with every day on their IT systems, but by bringing the right skills set into the products, we can ensure the right balance of security and usability.

JS: In general, how well are embedded device security maintenance and updating implemented?

JM: Most embedded devices, once fielded, are left alone, or at best “patched” when security vulnerabilities are identified. Once a vulnerability is discovered. However, it’s often just too late. Valuable information may have already been taken, or the system infiltrated with malware waiting for the right time to operate maliciously. Updates to these systems may require either physically connecting the system to a network or opening the device up to over-the-air (OTA) updates. This patching—which again may occur too late—requires secure communications.

MD: Typically, not well, unfortunately. Doing an over-the-air update securely is not trivial; you need a secure boot loader and lots of example code and documentation. It is important when selecting a vendor that you grill them on what enablement they have around this function.

HP: Traditionally, many update and maintenance schemes are not great. Many do not protect the code with proper signatures, enabling malware to be deployed, and many operate at a high level in the application space, whereas there is a clear need to presume almost every aspect of the system can be compromised. In fact, the first principle of updating should be every device can be compromised, and hence every device requires a safe-haven to recover and remediate from. In our solutions, we focus on the automatic creation of a robust Secure Boot Manager, which does all of the bare-metal work to ensure the device boots into a clear and secure space, where it can then check for a properly formatted, signed, and encrypted update. This multistage approach presumes that there will be many versions of software over the lifetime of a product, and hence, versioning and anti-rollback must also be integrated.

DH: I do not think there is a general answer to such a question since every device has different risks associated with it. You must make the assessment based on the goals of the particular device. If data is not a security risk, why protect it? Companies that do a proper risk assessment and then build mitigation based on the assessment will have a high level of confidence in their solution. Those that do not cannot make any meaningful claim.

JS: Do most embedded designers understand the importance of secure boot configurations and how and when to use secure boot to enhance embedded systems security?

MD: Secure boot in a microprocessor running Linux has been well understood and used extensively for the last five years or so. For a microcontroller with embedded flash, it is still a very new concept and one that not a lot of engineers have undertaken. The new IoT requirements from ETSI and NIST include authentication of code before runtime, which is forcing the conversation now in a microcontroller (MCU).

DH: Most embedded developers do not actually have anything to do with secure boot configurations. If the system designers’ risk assessment mandates secure boot, then specialists implement this.

JM: Knowledge of the importance of secure boot is more prevalent in the industries where the risk of devices being exploited is higher (e.g., avionics system, autonomous vehicle control systems, medical infusion pumps). These systems require the highest security and safety assurance levels since the life and safety of the device operator, passengers, or patient can be adversely affected by improper operation of the device. Secure boot configuration is often overlooked in loosely connected or standalone devices.

HP: Most embedded developers understand that secure boot managers are important; however, even with technologies like Arm TF-M, there is a need to build and support security systems for the long term. There is a global shortage of 3.5 Million cybersecurity experts, and so it is no surprise that these skills are in demand, and few engineers have the breadth of knowledge to understand what they are protecting, who they are protecting it from, and how best to implement the solution. The reality is the EN 303645 specification demands that all consumer embedded systems have a secure boot framework, and the IEC 62443 industrial IOT does the same in the industrial domain. There are practically no connected devices that do not require a robust, Secure Boot Manager.

JS: Thanks to our panelists for sharing their insights and experience! You might also be interested in reading “Functional Safety for Embedded Systems” – Virtual Roundtable (part 2 of 2).

Measuring the performance of AI and its impact on society – Virtual Conversation (part 2 of 2)

October 13, 2020 By Jeff Shepard Leave a Comment

Hosted by Jeff Shepard, EE World has organized this “virtual conversation” with Gary Bronner (GB), Senior Vice President with Rambus Labs. Mr. Bronner has generously agreed to share with us his experience and insights into AI applications and emerging computing architectures.

JS: When benchmarking AI performance, how would you rank the importance of throughput, latency, and accuracy?

GB: There really isn’t a one size fits all answer to this. Those things are valued very differently, depending on the specific application. It also depends upon whether you are looking at training or inference.

Gary Bronner (GB), Senior Vice President, Rambus Labs

For training, throughput is key. For inference, normally, one wants excellent latency, which makes it difficult to optimize for throughput. This is normally a trade-off that must be made. Training is all about collecting a bunch of things and then running them through together, which is more efficient from a throughput perspective but gives a longer latency. Inference is all about looking at a sample of one and quickly making a decision, which implies low latency.

The third important measurement to keep in mind is accuracy. You can improve throughput and latency but actually dramatically hurt accuracy. For example, I have seen situations where someone has built a really bad model. It doesn’t have very much computation at all. It’s not going to require very much data, and it’s not going to be very accurate, but I’m going to be able to get through it very quickly. And it is going to be very low latency to do the calculations. But the results are not acceptable. One needs to find an acceptable accuracy level for one’s application. It is a tough tradeoff since accuracy also affects energy. There is more power available in a data center than on a phone so that accuracy can be much higher.

JS: How is the perception of AI’s environmental impact changing, so-called “red AI”, and how might that perception change future developments in AI?

The environmental impact of the world’s collective “computing” is hugely important. According to results published in 2018, the world’s data centers consume ~ 1% of the world’s energy. To prevent this number from growing bigger, special attention will need to be paid. In the cloud, AI applications are immensely power-hungry, which makes efficiency even more important. And it’s expected that more and more AI will be done at the edge where many devices are battery-powered. As a result, I would expect to see a move away from “red AI” except for the most critical applications where power consumption trumps efficiency – for example, in the race to find a vaccine for COVID-19.

HBM2E is a high-performance memory that delivers higher overall throughput at a higher bandwidth-per-watt efficiency ideal for AI/ML and high-performance computing (HPC) applications. (Image: Rambus Labs)

JS: What are the societal implications, if any, of bias that may exist in AI inference engines?

GB: This isn’t a hardware issue, and so as a hardware company, this falls far outside Rambus’ purview. This is a challenge that needs to be addressed by the people coding and deploying the AI algorithms.

JS: Where do you expect AI and cognitive computing to have the largest impact in the near term? In the longer term?

GB: AI has made the most progress in deep learning applications, which are based on pattern matching. These are the applications where a lot of data can be learned and recognized by a computer. Such applications are already starting to have a large impact with significant positive results. For example, with Microsoft’s translation app, you can talk to your phone, and it will speak in a different language.

In the longer term, if we could get to something that is more towards the direction of what’s called artificial general intelligence (AGI), meaning intelligence, more like a human, I think that would have a very large impact. But it is very unclear when we are actually going to get there. Discussion in the community puts it in a range anywhere from five to a few hundred years.

JS: Thank you to Mr. Bronner, for sharing his insights and experience, another great conversation! You might also be interested in reading “AI applications and emerging computing architectures” – Virtual Conversation (part 1 of 2).

AI applications and emerging computing architectures – Virtual Conversation (part 1 of 2)

October 12, 2020 By Jeff Shepard Leave a Comment

Hosted by Jeff Shepard, EE World has organized this “virtual conversation” with Gary Bronner (GB), Senior Vice President with Rambus Labs. Mr. Bronner has generously agreed to share his experience and insights into AI applications and emerging computing architectures.

JS: What is usually the biggest challenge designers face when first using artificial intelligence?

GB: One of the biggest challenges designers face when first using AI is that it requires a careful balancing of processing and memory. A fast AI accelerator needs a memory system feeding it enough data to stay busy. It is very hard to get the ratio of accelerator performance to memory bandwidth right, or even know what it should be unless you understand the specific problem you are working on and what the workloads will be. This is why memory, or, more precisely, the type of memory, is so important for AI. Both GDDR6 and HBM2 are widely used in AI systems. The choice between them comes down to tradeoffs in cost, power, chip area, and design complexity.

JS: What is the most misunderstood aspect of AI, and how does that translate into specific design challenges?

GB: A common misconception is that all AI or deep learning applications work the same. Depending on whether you are doing image recognition or speech or translation or any of the other applications of deep learning, the architecture that will work best for a specific system is actually very different. There are several approaches that can significantly change the architecture of the system. So when you design hardware, you can’t just think of one. For example, you could build the best machine for convolutional networks that will allow you to do great image recognition. However, it wouldn’t work as well if you used the same machine as a translator.

The other thing that is important to remember is that the field is still evolving, with new algorithms being produced almost every day. How do you design a system to be useful for algorithms that haven’t been invented yet? Some of the ability to answer that question depends on how good your crystal ball is.

More practically, it translates to keeping in mind how much bandwidth you need today as well as how much you’ll need in the future. Architecturally, it’s about figuring out how to flexibly route resources around the various compute elements. For example, the higher performance of an AI accelerator means it needs more and more data to keep itself busy and productive. Which drives the need for high-performance memory systems, and very high bandwidth memory interfaces, either GDDR6 or various HBMx generations, both of which Rambus helps enable.

GDDR6 is a high-performance memory solution that can be used in various applications requiring high memory throughput, such as ADAS, data center, and AI. (Image: Rambus Labs)

What it ultimately boils down to is you need to design a system that is very optimized, but not completely specialized, to provide some added flexibility.

JS: Considering AI accelerators using CPUs, GPUs, and FPGAs, what are the tradeoffs in terms of specific application features and benefits of each of those approaches?

GB: As the saying goes, “you can have something done cheap, fast, or right – pick two.” The same concept applies here; AI accelerators can be fast, energy-efficient, or flexible, but not all three.

CPUs are general-purpose, so they are the least expensive but provide the lowest performance for AI and are the least power efficient. FPGAs offer better performance and power efficiency compared to CPUs, but they are not as performant as GPUs. However, they offer a level of flexibility that makes them good for prototyping or addressing the rapidly evolving algorithms. As a result, we’re currently seeing FPGAs used frequently for AI accelerators. GPUs lack the flexibility of FPGAs but offer better performance and power efficiency.

I think there is actually a fourth approach to build an AI accelerator – custom ASICs. An ASIC is probably the highest performance and highest efficiency approach once you are confident that the algorithms are relatively set. The challenge with them is it can take six months to design an ASIC, by which point the algorithm it was designed for would be too old, and the process would have to be started over.

JS: Do you expect to see new computing architectures emerge optimized specifically for AI? If so, what should we expect to see in this area?

GB: Yes, we are already seeing what is being referred to as a new “golden age of computing,” which is resulting in many specialized chips. We are seeing this tremendous need for ever-increasing performance that is manifesting in new technology such as Google’s TPU, startups such as Cerebras Systems, along with probably more than 30 or 40 other designs in various stages of deployment. These applications are good at running AI, and because there is such high demand, there’s an astonishing ability to fund it, continuing to drive performance and efficiency.

This can be further broken down into data center and edge. At the edge, the big concern is achieving efficient implementation of machine learning functions for more inference tasks. For example, we need Alexa to recognize the “hot word.” Whereas what is important in the data center—where the training takes place—is attaining the highest performance to improve machine learning algorithms.

Right now, the number of architectures is growing rapidly as the industry evolves and tries to figure out what’s going to ultimately work best. This will eventually lead to a kind of natural selection where we’ll see a few of the best solutions become de facto standards.

JS: Thank you to Mr. Bronner, for sharing his insights and experience, great conversation! You might also be interested in reading “Measuring the performance of AI and its impact on society” Virtual Conversation (part 2 of 2).

Embedded systems software and programming for a safer world

October 9, 2020 By Jeff Shepard Leave a Comment

Functional safety is an important feature in many embedded systems today. Designers need to know the specific safety integrity levels that must be met in various application environments and software development standards and guidelines. The use of an integrated development environment can efficiently bring these various requirements together to maximize the productivity of the development process and the quality of the resulting embedded system software.

Some of the most common functional safety standards include:

IEC 61508 is the international umbrella standard for functional safety. The standard, and standards derived from it, are used within all kinds of industries with requirements on reliability and safety, for example, process industries, the oil and gas industry, nuclear power plants, machinery, and railway control systems.
ISO 26262 is used for automotive safety-related systems.
EN 50128 and EN 50657 are European standards for safety-related software in railway applications. The standards are derived from IEC 61508.
IEC 62304 is an international standard which specifies life cycle requirements for developing medical software and software within medical devices.

High-integrity functional safety standards frequently require designers to provide extensive justification for selecting a particular development tool unless the tool is already certified. The proof of compliance for the tools increases cost and time of development. Pre-certified tools can provide an answer to this need.

For example, IAR Systems provides certified editions of IAR Embedded Workbench for Arm, for Renesas RX, RL78, and RH850, and for STM8. The tools’ functional safety editions are certified by TÜV SÜD according to the requirements of IEC 61508, ISO 26262 (ISO 26262-6:2018), EN 50128, and EN 50657. For Arm, RX, RL78, and STM8, the certification also covers IEC 62304.

Embedded systems software and programming — The IAR embedded workbench includes functional safety editions tools certified by TÜV SÜD. (Image: IAR Systems)

Safety integrity levels

The concepts and requirements for various safety integrity levels (SILs) are not consistent among all functional safety standards. Based on the IEC 61508 standard, four SILs are defined in the functional safety standards, with SIL 4 the most dependable and SIL 1 the least. IEC 61508 defines SIL using requirements grouped into two broad categories: hardware safety integrity and systematic safety integrity. A device or system must meet the requirements for both categories to achieve a given SIL. In addition, there are different SIL requirements for systems that operate continuously compared with systems that are used intermittently. The “probability of dangerous failure on demand” (PDF) and the “risk reduction factor” (RRF) can be 10,000-times more stringent for systems that operate continuously compared with systems that are used intermittently.

For embedded industrial applications, Renesas Electronics recently announced the extension of their RX Functional Safety solution, with the release of its Functional Safety over EtherCAT (FSoE) Application Software Kit, the first software offering that supports functional safety on EtherCAT from a semiconductor manufacturer. Renesas’ RX Functional Safety solution is a solution for industrial automation applications that reduces the complexity of IEC 61508 SIL3 certification.

Renesas offers a Functional Safety over EtherCAT (FSoE) application software kit for industrial systems (Image: Renesas)

Renesas’ new FSoE software is based on the FSoE standard published by the EtherCAT Technology Group, the world’s largest industrial Ethernet organization. Developers can obtain an FSoE protocol stack in addition to an RX microcontroller (MCU) with functional safety support and the software – all in a single package, speeding up the development of industrial equipment incorporating FSoE. This allows the quick implementation of communication functions needed to support functional safety, such as essential alarms indicating danger or emergency stop signals using an RX MCU.

Automotive safety integrity levels

While IEC 61508 defines four safety integrity levels from 1 to 4, ISO 26262 defines four automotive safety integrity levels (ASILs) from A to D. ASIL A is the least stringent level of safety reduction, while ASIL D is the most severe. ISO 26262 applies to vehicles with a maximum gross vehicle mass of up to 3,500 kg (about 7,700 pounds).

ASIL classifications of representative automotive systems (source: Synopsys)

Car manufacturers and system suppliers have traditionally addressed compliance with these requirements. However, with the increasing complexity of automobiles, all supply chain participants are now called to support and enable functional safety and reliability standards. These metrics are becoming an integral part of the semiconductor design flow.

According to ISO 26262:1-2011, a safety mechanism is a technical solution implemented by electrical or electronic functions or elements, or by other technologies, to detect faults or control failures to achieve or maintain a safe state. Examples of safety mechanisms include:

Error correction code (ECC)
Cyclic redundancy check (CRC)
Hardware redundancy
Built-in-self-test (BIST)

The effectiveness of the solution to detect these random failures is measured by three metrics to detect fault and failure in time (FIT), as well as the overall likelihood of risk:

Single-point fault metric (SPFM)
Latent fault metric (LFM)
Probabilistic metrics for hardware failures (PMHF)

MISRA C

MISRA C is a set of software development guidelines for the C programming language developed by MISRA (Motor Industry Software Reliability Association). It aims to facilitate code safety, security, portability, and reliability in the context of embedded systems, specifically those systems programmed in ISO C / C90 / C99. There is also a set of guidelines for MISRA C++. Although originally specifically targeted at the automotive industry, MISRA C has evolved as a widely accepted model for best practices by leading developers in sectors including automotive, aerospace, telecom, medical devices, defense, railway, and others.

MISRA is a collaboration between manufacturers, component suppliers, and engineering consultancies, which seeks to promote best practice in developing safety- and security-related electronic systems and other software-intensive applications. For a claim of MISRA compliance to have meaning, it is necessary to establish:

Use of a disciplined software development process;
Exactly which guidelines are being applied;
The effectiveness of the enforcement methods;
The extent of any deviations from the guidelines;
The status of any software components developed outside of the project.

Integrated development environment

Regardless of the programming language, standards, or applications environment, embedded software designers need an integrated development environment (IDE). IDEs are designed to maximize programmer productivity by providing a set of development tools with similar user interfaces. IDEs present a single program in which all development is done. This program typically provides many features for authoring, modifying, compiling, deploying, and debugging software.

Examples of the tools included in IDEs are debuggers and emulators. The debugger goes through the code and eliminates bugs and errors, notifying the programmer where they occur. Debuggers pinpoint the lines where issues are found so that programmers can address them quickly.

An emulator is a hardware or software replication of the target system with identical functionality and components. Emulators are used to simulate software performance and see how the code will work in a real-time environment. With an emulator, programmers can change values to reach optimal performance of the code.

This was the final article in a three-part FAQ series on various aspects of embedded system design. The first article looked at managing power consumption and dissipation in embedded systems for a greener world. The second article considered securing embedded systems in a hostile world.

References

Functional Safety Methodologies for Automotive Applications, Cadence
Functional Safety Solution for Industrial Automation, Renesas Electronics
MISRA Compliance:2020, MISRA
Integrated code analysis in functional safety tools, IAR Systems
Safety integrity level, Wikipedia
What is ASIL?, Synopsys

Securing embedded systems in a hostile world

October 8, 2020 By Jeff Shepard Leave a Comment

The design of security for embedded systems is a critical and difficult task. Security requirements are often not fully identified at the beginning of the project. Once they have been identified they are not necessarily static and can change multiple times through the design cycle. One reason for changing security requirements is that the various cyber threats and threat vectors are constantly evolving. As a result, the ability to update system security software throughout a system’s operating life is an important design consideration. Encryption is a common element across all embedded system security designs.

The Advanced Encryption Standard (AES) is an algorithm used to encrypt and decrypt data to protect the data when it is transmitted electronically. AES supersedes the Data Encryption Standard (DES). The algorithm described by AES is a symmetric-key algorithm, meaning the same key is used for both encrypting and decrypting the data.

The AES algorithm allows for the use of cipher keys that are 128, 192, or 256 bits long to protect data in 16-byte blocks. AES is a U.S. Federal Information Processing Standards approved algorithm that is also approved for commercial and private applications. AES is widely used in a variety of applications. Data encryption is only one aspect of security design in embedded systems. There are firmware and software tools for enhancing embedded systems’ security against various threats and attack vectors.

Differential power analysis attacks

Differential power analysis (DPA) is a security attack which involves statistically analyzing power consumption measurements from a cryptosystem. The attack exploits varying power consumption of microprocessors or other hardware while performing operations using secret keys. DPA attacks have signal processing and error correction properties, which can extract secrets from measurements which contain too much noise to be analyzed using simple power analysis. Using DPA, an adversary can obtain secret keys by analyzing power consumption measurements from multiple cryptographic operations performed by a vulnerable smart card or other device.

A DPA attack requires hands-on access to the device (Image: Silicon Laboratories)

Power analysis attacks cannot generally be detected by a device, since the adversary’s monitoring is normally passive. In addition, the attack is non-invasive. Some countermeasure strategies to protect against DPA attacks involve algorithmic modifications such that the cryptographic operations occur on data that is related to the actual value by some mathematical relationship that survives the cryptographic operation.

One approach involves blinding parameters to randomize their value. Other countermeasure strategies to reduce DPA attacks’ effectiveness involve hardware modifications: varying the chip internal clock frequency can be used to desynchronize electric signals.

Evaluation assurance level

The Evaluation Assurance Level (EAL) of an embedded device is a numerical value from 1 to 7 that is determined using an internationally standardized “Common Criteria” security evaluation. The higher the EAL levels, the more detailed the verification and testing requirements are outlined in the corresponding devices “Security Target” document. A higher EAL level does not necessarily identify a “more secure” device. It simply indicates more thorough testing and verification process. In the case of two devices having the same Security Target definitions, the higher rating device should be more trustworthy. EAL levels are defines as follows:

EAL1: Functionally Tested
EAL2: Structurally Tested
EAL3: Methodically Tested and Checked
EAL4: Methodically Designed, Tested, and Reviewed
EAL5: Semiformally Designed and Tested
EAL6: Semiformally Verified Design and Tested
EAL7: Formally Verified Design and Tested

The EAL requirements can also be augmented to include assurance requirements more extensive than the minimum needed for a given EAL. Augmented EALs can be indicated using the word “augmented” or using a “plus” sign as in EAL5+.

For example, STMicroelectronics offers its STSAFE-A110 Secure Element that can protect consumer and industrial connected devices in the Internet of Things (IoT), preventing the counterfeiting of genuine products by strictly assuring their authenticity. The device features an embedded secure operating system and is based on hardware that is certified to Common Criteria EAL5+. Each unit comes with a unique identification and X.509 certificates that aids secure device connection. STSAFE-A110 is designed for use as brand protection for components like consumables, accessories, power-tool batteries, and the authentication of cloud-connected IoT devices such as vending machines, farm implements, etc. environmental sensors.

STSAFE-A100 Secure Element from STMicroelectronics meets EAL5+ (Image: STMicroelectronics)

Secure boot configurations

In addition to hardware-based security devices such as the STSAFE-A100 described above, there are software and firmware tools for enhancing the security of embedded devices. Secure boot is a feature in the Unified Extensible Firmware Interface (UEFI) 2.3.1 specification. Secure boot defines an interface between the operating system and firmware/BIOS. Secure boot can detect tampering with boot loaders, key operating system files, and unauthorized option ROMs by validating their digital signatures. Detections are blocked from running before they can attack or infect the system.

The dual-core architecture of PSoC 6 is designed for establishing isolated processing environments (Image: Renesas)

For example, the PSoC 64 Secure MCUs from the Cypress subsidiary of Infineon Technologies is embedded with a Cypress-owned Root of Trust (RoT) when it comes out of the factory. This RoT is based on a public key that is owned by Cypress. When an OEM customer purchases devices, there is a secure process to transfer the RoT to the OEM. This process replaces the Cypress public key with the OEM’s public key. From that point on, the OEM “owns” the device, and the secure device will only accept any further security-related interaction if it is appropriately signed by the OEM. To work with Secure devices, the designer provides three “things”:

A set of cryptographic keys, the public key of which will be used for validating OEM application firmware
A set of security policies that define how the secure chip should behave
Certificates (optional) used to bind device identity or provide a chain-of-trust to a higher certifying authority

This information, along with the bootloader, is securely injected into the device before the firmware is programmed. The process is called provisioning. The information provides the rules that the ROM boot code follows when launching the bootloader and provides the resources required to verify the code’s authenticity. The designer develops the software to run on the device and digitally signs the application using a private key that corresponds to the device’s keys. With policies and keys in place, the ROM boot code verifies the bootloader, which verifies the signature and the integrity of any code before launching it.

This was the second article in a three-part FAQ series on embedded system design. The first article looked at managing power consumption and dissipation in embedded systems for a greener world. The third and final article in this series will look at embedded systems software and programming for a safer world.

References:

Advanced Encryption Standard, Silicon Laboratories
Differential Power Analysis Countermeasures, Silicon Laboratories
Evaluation Assurance Level, Wikipedia
Power analysis, Wikipedia
Security for the Connected World, Renesas

Managing power consumption and dissipation in embedded systems for a greener world

October 7, 2020 By Jeff Shepard Leave a Comment

Three of the keys to successfully managing power consumption and dissipation in embedded systems are using various active power management techniques, power-aware code and software optimization, and making power management an integral part of the design flow process from the beginning.

Active power management can include the use of power gating, clock gating, dynamic voltage scaling, and adaptive voltage scaling. Power gating involves putting circuit blocks and subsystems that are not currently being used in standby. It is one of the simplest forms of active power management. Implementation of power gating involves balancing the amount of energy saved by using standby for a particular block with the energy consumed to start and stop the block’s operation. Power gating is typically implemented using a combination of hardware and software control.

Memory systems are often a candidate for power gating. In the case of power gating memory blocks, the amount of energy saved varies based on each application system’s usage patterns. For example, with non-volatile memories, the write power is typically much higher than the read or standby power. That means that write times need to be minimized in power critical designs, especially in systems that require frequent writes to memory.

The power-up time for the specific memory being used is a critical consideration for power gating. Memories with faster power-up times can be placed into standby more frequently. A second important consideration is the leakage current when in standby mode. The higher the standby leakage current, the less the benefit from power gating.

While power gating aims to reduce the leakage power in a circuit, clock gating aims to reduce dynamic power. Clock gating removes the clock signal when the circuit is not in use. Clock gating saves power by pruning the clock tree, at the cost of adding more logic to a circuit. Pruning the clock disables portions of the circuitry so that the flip-flops in them do not have to switch states. Switching states consume power. When not being switched, the switching power consumption goes to zero, and only leakage currents are incurred.

Voltage scaling

Voltage scaling is typically implemented in one of three ways; dynamic voltage scaling (DVS), dynamic voltage and frequency scaling (DVFS), and adaptive voltage scaling (AVS). AVS is a closed-loop dynamic power minimization technique. AVS allows the voltage supplied to the chip, and therefore its power consumption, to be continuously adjusted to be appropriate to the workload and the parameters of the specific chip. This is accomplished by integrating a device that monitors the performance of the chip (a hardware performance manager) into the chip, which then provides information to a power controller.

AVS is similar in its goal to DVS and DVFS. AVS provides greater power savings compared with DVS and DVFS, which are open-loop techniques. All three approaches aim to reduce power usage and heat generation. AVS adapts the voltage directly to the conditions on the chip, allowing it to address real-time power requirements and chip-to-chip variations and changes in performance that occur as the chip ages. The advantages of AVS include:

Delivery of the desired voltage to every block of the system despite variations in temperature, process corner, and frequency;
Processor- and architecture-independent implementation of power reduction;
Typical savings of about 55% compared to open-loop Dynamic Voltage Scaling approaches.

Energy savings using open standard PowerWise adaptive voltage scaling (Image: Texas Instruments)

Performance implications of AVS

The use of AVS has device performance implications that need to be considered by designers. For example, in battery-powered systems with an input voltage of 3.6V, it may be most efficient to power internal logic and flash memory using a high-efficiency dc/dc converter. As the battery discharges and the battery voltage declines, it can be more efficient to power the flash and internal logic from different sources because the internal logic can operate at lower voltages than the memory. For example, the SiM3LK1xx low-power 32-bit MCU family from Silicon Laboratories has a flexible power architecture with six separate and variable power domains that enable dynamic optimization.

CMOS logic circuits typically operate more slowly at lower input voltages. If the application can tolerate lower performance, then reducing energy consumption using AVS and a lower voltage can provide substantial energy savings. Leakage provides a lower limit on the effectiveness of AVS. For example, if a particular function takes too long when performed with a lower voltage, leakage will begin to dominate the energy equation and increase overall energy consumption. In these cases, it can make sense to execute a function as quickly as possible (at a relatively higher voltage) and then put the processor into sleep mode to minimize the leakage component.

Power-aware code and software execution optimization

Energy-Aware Scheduling (EAS) is an enhancement to Linux power management, placing CPU power control directly under the Linux scheduler. When enabled, EAS uses the task load and a CPU Energy Model to select the most efficient CPU to run on, taking advantage of the power and performance of Arm big.LITTLE and Arm DynamIQ-based systems. EAS is tightly connected with the Linux DVFS subsystem. EAS is merged into upstream Linux as of kernel v5.0 and later.

The figure below shows test results using EAS on an Arm Juno r0 platform using RT-App (a synthetic workload generator) in a low-intensity scenario where energy consumption is the primary concern and using Hackbench as a performance benchmark.

Linux Energy-Aware Scheduling can reduce power consumption without a significant impact on system performance (Image: ARM)

Power-aware verification

Power-optimization techniques are creating new complexities in the physical and functional behavior of electronic designs. An integral piece of a functional verification plan. For example, Cadence offers a power-aware verification methodology that can help verify power optimization without impacting design intent, minimizing late-cycle errors and debugging cycles.

The methodology brings together power-aware elaboration with formal analysis and simulation. With power-aware elaboration, all of the blocks and the power management features in a design are in place so that designers can verify the design with power intent. Power intent introduces power/ground nets, voltage levels, power switches, isolation cells, and state retention registers. Any verification technology—simulation, emulation, prototyping, or formal—can be applied to a power-aware elaboration of the design.

Power-aware verification methodology example (Image: Cadence)

The integration of code scheduling, power gating, adaptive voltage scaling, and power-aware code can increase energy savings and lower dissipation in embedded systems.

This was the first article in a three-part FAQ series on various aspects of embedded system design. The second article will consider securing embedded systems in a hostile world. The third and final article in this series will look at embedded systems software and programming for a safer world.

References

Adaptive voltage scaling, Wikipedia
Adaptive voltage scaling technology, Texas Instruments
Designing Low-Energy Embedded Systems from Silicon to Software Part 2 – Software Decisions, Silicon Laboratories
Energy Aware Scheduling (EAS) in Linux 5.0, arm
Power-Aware Verification Methodology, Cadence
Power gating, Wikipedia

Jeff Shepard

Quantum compasses and optical imaging for global positioning and navigation

eLORAN a terrestrial alternative to GPS

GPS is a ubiquitous and problematic technology

Functional safety for embedded systems – Virtual Roundtable (part 2 of 2)

Security for embedded systems – Virtual Roundtable (part 1 of 2)

Measuring the performance of AI and its impact on society – Virtual Conversation (part 2 of 2)

AI applications and emerging computing architectures – Virtual Conversation (part 1 of 2)

Embedded systems software and programming for a safer world

Securing embedded systems in a hostile world

Managing power consumption and dissipation in embedded systems for a greener world

EE World Online Network

Microcontroller Tips

Jeff Shepard

Footer

EE World Online Network

Microcontroller Tips