Customization And Limitations At The Edge

Semiconductor Engineering sat down to discuss the edge constraints and the need for security with Jeff DeAngelis, managing director of the Industrial and Healthcare Business Unit at Maxim Integrated; Norman Chang, chief technologist at Ansys; Andrew Grant, senior director of artificial intelligence at Imagination Technologies; Thomas Ensergueix, senior director of the automotive and IoT line of business at Arm; Vinay Mehta, inference technical marketing manager at Flex Logix; and John Sanguinetti, CTO of Adapt. What follows are excerpts of that conversation. (Part 1 of this discussion can be found here. Part 2 is here).

SE: As we add more intelligence, we have to do significantly more processing. Do we take the brute force way and just add more transistors and processing power, which also raises the cost, or do we need to look at the problem differently?

Mehta: These are complex problems that need to be looked at differently. When you talk about like fault-tolerant systems and reliable systems, such as automation, those are very dependent on validation and verification of a state machine. For example, will you end up in a left turn lane with no power, or with the cameras blinded? Maybe you need to abort that turn because someone has come into the lane in front of you and you might end up in an unsafe state if you continue. That’s where we see a combinatorial explosion of decision-making trees, and we have to start applying intelligence to these decisions where prior knowledge is not enough to a guess trigger an action in the physical world.

Ensergueix: If you believe we’re going to go scale to billions and maybe a trillion transistors one day, we won’t be able to put batteries in all of them. We will always have a very limited power budget for all the devices, and something we’ve been looking at in Arm is how to enable hardware-software co-design. For example, in our latest generation of CPUs, we are enabling our partners to add their own instructions. Arm Custom Instruction, which we launched recently, is a step toward opening up our architecture and instruction set for data processing on sensors, especially. If you have some specific magic, you can better implement that with bespoke instructions, and you can extend the Arm ISA to do so.

Mehta: When you make a new instruction on an ARM processor, are you just creating sub-routines like other op-codes that are already available in the Arm instruction set, or are you defining a brand new physical architecture that requires different compute units?

Ensergueix: For us, software consistency is extremely important. We have a subset of the ISA, which you can touch. There are some op codes, which are free and open for you to define what you should be doing. The rest of the architecture remains sound and consistent with the Arm architecture or the tools, but you have a given set of the interconnect space in which you can directly plug in your own datapath to do some some magic on on the data.

Mehta: So you’re integrating your own physical IP, and then also writing the software to take advantage of that physical IP.

Ensergueix: Yes, but we have been very careful not to break the ISA, so all the tools are there. You don’t want to touch it. So you’re just extending it, not breaking anything which already exists.

Chang: There are three unique characteristics of an intelligent device. One is very low power. So you need hardware-software co-design, and machine learning/deep neural networks performing at very low power. The second thing is reliability for adapting to the environmental conditions. It needs to work in all conditions, and you need to consider thermal integrity, power integrity, signal integrity, ESD, and many, many other aspects. The third thing is security. We cannot forget about security, and we need to make sure there’s no breach or that attackers can come in to the intelligent edge device and into the server and into the company.

Grant: Digital twins are really important in this space. We’ve seen that with jet engines. But just coming back to the hardware-software angle, the software guys are the unsung heroes of what what we do. In a situation where you’re creating IP — in our case for edge GPUs — you’ve often got a situation where you’re releasing RTL, and the software environment is being built at the same time. You need platforms, which are architectural models, so you can work through some of these implementations for the intended trajectory of where customers can go. We have something called AI Synergy, where you can leverage the GPU and neural network accelerator for what they do best. So you’re using HyperLane technology, which is our term for it on the GPU and running different tasks. That requires a lot of work at the driver level and software level of the SDK. There’s a huge amount of work that goes into the code design. And then, obviously, we are reaching out and working with the SoC builders, and beyond that to their end customers. What do they actually want to run on the device, and how can you make sure that you’re optimizing it for them?

SE: As we start designing devices that are supposed to optimize over time, security becomes more of a moving target. Algorithms are changing on a regular basis, and training data can cause problems for entire classes of devices. How do we prevent problems in the future?

Ensergueix: You definitely need very robust over-the-air firmware updates. And even if you agree with them, your applications are changing. So you need to have a ground-up, very solid root of trust, which will be unchanged probably during the life of the device. That root of trust is there to identify and ensure your connection to the network. Then, thanks to that, you can update your algorithms. Stability is the key. You cannot expect when you are releasing devices for 5 or 10 years, that they will be completely secure. You always will find a back door or a failure somewhere that you can attack over this time frame.

DeAngelis: Security is a very complex world. At the edge, the customers I engage with are not too keen on implementing a high level of security. Mostly what they’re trying to protect and validate is whether that device at the edge of a network is an approved device. Is it one that I know my technician installed? Is it one that is similar to what originally was commissioned on the network? There’s also more security as you move from the edge inward, where security becomes more sophisticated. You want to make sure no one’s breaching the network, and there you can tell if there’s a breach or some type of intrusion. So we have very simple device-level security that we embed into the the IC itself, which is PUF technology. It’s a pseudo random type of cell that has a sense of characteristics, based on the chip’s manufacturing process. And depending on where the chip sits on the wafer, it has a very unique identifier. This way you build security into every IC, which then can be accessed by a security algorithm. There is a unique identifier to ensure that device is secure. There’s also sophisticated software running on a big embedded controller or microprocessor. So we have the full gamut. But at the edge, it has to be simple. A lot of these are compact devices that are very power-efficient. You can’t afford to have sophisticated local security at the edge. It has to be simple enough where the customer understands that device was commissioned and that it’s a real device. When you first install a device, you commission it. It’s kind of like when you’re adding a new wireless node in your house. You push the button on the wireless router and say, ‘Find the device.’ We’re using a similar type of concept at the edge for these devices. And then, with some of these technologies, you’re able to go and interrogate the device. If someone just installed a different device, like someone physically is connecting for the second time, you can ask whether this device is an exact copy of what was just installed on network based on the commissioning. Or is this something different? And depending on what you get back, you actually can impose different levels of restrictions on the device. You either can shut it down and say, ‘Hey, I don’t recognize you and we’re not going to take any information into the network based on on what you’re giving me.’ Or you can say, ‘Yeah, you’re like what was on here before. So maybe I would just restrict some basic level of information that you can pull, or it will be pull only and you just push data out to that device. Or you could say, ‘Hey, you’re the same. You’re commissioned. No problem.’ But we’re not looking at high levels of intense type of security for edge devices. They’re simple. There’s not a lot of data usually that goes on at these edge devices. Everyone wants to impose these high levels of encryption in these devices, but there’s no way that’s going to happen. There are various levels of security that are important.

Mehta: This is how Microsoft determines valid Windows licenses. If you change out the GPU, you know it’s a different system. Is this a valid license? You’ve changed out so many components on your system, so is this still the same system? The customers don’t understand the implications of a security breach until it impacts them. Then they’re scarred and they want protection against this kind of breach. But how much of a selling value proposition does enhanced security add if your customer isn’t scared of a problem?

DeAngelis: Yes, it doesn’t add a lot of value unless they’ve been through an attack.

Grant: Historically, security has been done at the application level, and we just provide the hooks to make it work. But going forward, all devices will need to be secured. With edge devices, you want to keep as much information private as you possibly can. So with the coronavirus tracking, how do you know when someone calls that it’s a reliable source? And what are they picking up from me? But I agree that at the very end of the sensor that data doesn’t need to be secured in the same way as something that’s sitting in the CPU or in a defibrillator. It’s something we’ve all got to be aware of, because the next attack is going to come from outside the walls of what we expect.

Ensergueix: It has to be the right size security, but sometimes even a basic device could do a lot of damage if it is being hacked. One example is a connected light bulb. If you are able to take control of 100,000 or 1 million lightbulbs and you turn them off and on repeatedly, you could take down a city grid. There is no data or intelligence really in this light bulb, but just being able to control can do a lot of damage.

Sanguinetti: From what we we deal, which is security on the wireless protocol, we can do more than we have in the past. The new WiFi HaLow has WPA3 security and it’s as good as or better than what we what’s out there now. It’s a way of protecting the data that’s being transmitted over the air, but that’s only the bottom level of the security stack. For sensors, that’s probably adequate and it’s not terribly power-intensive or impractical to deploy at scale. But this area is going to develop over the next few years and requirements are going to continue to become more comprehensive. Security techniques are going to have to improve continuously.