EE Times and EDN are running a series of regularly scheduled interviews with members of the EDN Editorial Advisory Board. Here, we meet Lars Reger, CTO of NXP Semiconductors. In December 2018 Lars was appointed CTO and has since then been responsible for the overall technology portfolio of NXP. Richard Quinnell, editor-in-chief of EDN, Junko Yoshida, global co-editor-in-chief of Aspencore Media, and Nitin Dahad, a correspondent at EE Times and editor-in-chief of embedded.com joined in the conversation with Reger.
As we move more and more to a heavily connected, on-demand world, how do engineering skills need to change? This is uppermost on the mind of Lar Reger, CTO, as he explores the needs of his company and the electronics industry.
He’s very conscious of the fact that the prospect of 75 billion connected devices by 2025 presents challenges related to trust, privacy, security and managing risk. Reger believes these are vital, and he illustrated them with some examples. “How can I make sure that my fridge can never be hacked? Because if this thing starts ordering five hundred liters of milk for the weekend, I’m doomed.” Or, he says, “How can I functionally assure safety? Because if my iron for my shirts burns down my house then I will not tolerate this thing next to me, and I’ll go with un-ironed shirts.”
The skills needed to design for trust, security and safety will hence be paramount, and will require understanding de-centralized networked systems and devices.
Trust in the age of smart connected devices
Richard Quinnell: What are the new and emerging technologies that engineers need to start learning about?
Lars Reger: Fifteen years ago, I had a complete manual world around me with a couple of electronic helpers. When I was coming home from vacation, I would call my neighbors, and ask them to switch on the heating in my house. That was my smart home. Today, in an on-demand world, I take out my mobile phone and call for an Uber now. Or I can [remotely] switch on or off my heating.
We are moving towards a world that anticipates and automates. So, like Queen said 30 years ago, “I want it all. And I want it now.” But of course, this all happens without you having to take action, since in theory the world will automatically adjust around you, because of the 75 billion smart connected devices around us. A smart connected device includes your smart watch, your intelligent speaker, your building robot and your autonomous cars.
This puts us in an era of decentralized devices. Engineers have traditionally always followed Moore’s Law: with microcontroller, new technology node, more transistors, so more powerful and less energy consuming. That is basically the boring trend that every node was following. And what can the new technology node give me?
If you want to go to the 75 billion smart connected devices and if they are the mighty steering of our planet — and by the way, also the way to an eco-friendly world — then I need engineers who understand networking systems, distributed systems. A lot of us at the moment are becoming somewhat expert in decentralized, distributed systems by learning about Covid-19. How does exponential growth, exponential reaction, virus systems and so on work?
Engineers need to understand how to build these systems on a much lower compute performance, much smaller energy footprint. They’re networked with high quality sensing, whether designing a Nest thermostat or a self-driving car. Now, what engineers have done so far is optimize these tiny little devices or the big computer systems. But what is coming and what engineers are not effectively trained in saying is, “How do you enable the end user to trust his devices?”
“Trust your device” is the big enabler or disabler for entire markets.”
Super-disciplined architectural thinking needed
Richard Quinnell: These are lofty goals. I was hoping to get a little more insight into specific steps. You mentioned the need to be functionally safe by design, secure by design. What specifically do engineers need to achieve this?
Lars Reger: Trust had not been of paramount importance in the past because your devices were not connected. While functional safety might have been understood, the security part was of low importance. Now you need to have engineers who do privacy by design or security by design and functional safety by design, because otherwise you can hardly qualify and build.
Take a car: the most expensive and most complicated of these smart connected devices. If you try to change one component in your car and you would have to requalify your complete autonomous electric driven connected vehicle: that’s an undoable task, in terms of manpower and money. You need to have an architectural understanding to break up the smart connected device into sub-domains that are very strictly separate from each other. How do I separate the powertrain of my car from the gateway, from the connectivity domain, and from the autonomy domain? And if I changed the autonomy domain, how do I enable this without having to requalify the powertrain? This type of super-disciplined thinking is important.
We have development handbooks – my chip development handbook has 5,000 pages. In most cases, it’s not that the product development has not been described. But think for example if in our development an airline pilot thinks they can take off without having checked the fuel level, but just by assuming that the plane is fueled. If something goes wrong, it is a result of lack of discipline. This has mighty implications if you are sloppy in one or another area.
This disciplined thinking is what each and every engineer needs to have – and if they did, that would of course, be the game changer, with millions and tens of million dollars of impacts on our big projects.
Education on functional safety and security
Richard Quinnell: Is there is a fundamental starting point that we need?
Lars Reger: Look, I mean, show me the university that has lectures on functional safety and functional security in their curriculum. In the automotive industry, if you have really mastered this, you have ISO 26262, which is basically the functional safety processes, and how we treat systems.
In layman’s terms, this means carrying out risk assessments starting from the system level. How do you assess a car and how do you make sure that this thing never, ever causes a fatality? Then you break it down into sub-systems, for example the braking system, to make sure this never, ever causes a fatality.
The skill you need is in building functional safety into the process. But this really must work down the scale to the component level of a semiconductor. I give you an example. Years ago, with the biggest tier one that we have, we had a discussion in which they asked, “Can you please bring two ABS sensors in one housing for redundancy purposes?”
The logic was that if one of the wheel speed sensors failed, you had a redundant one sitting right next to it. We had a discussion and said, that’s complete nonsense because you have four wheels on the road. If you get data from three wheels indicating you are running a hundred rounds per minute, and one is sending data saying it is running at ten rounds per minute then, you already have a check. You have a system capability already to find out that one sensor is [potentially] corrupt. So, you do not need to double the cost per sensor by doubling the packaging and qualification requirements. That’s a very oversimplified and exaggerated example. But this is what I mean by driving down the system cost. Using system capabilities but going really from a high-level risk assessment in a structured way down to the component.
In the same manner, industry is looking at the security of systems. Using a house analogy, you want your house to be unattackable. So, you put a big lock at the front door and a big lock at the backdoor. That’s basically your connectivity unit with big firewalls. Or say you have a big castle with hundreds of rooms. Your wiring harness is all the aisles to the rooms in your in your castle. These rooms are your ECUs, your control units. You have a door lock at every point. So, every microcontroller has a certain level of security and you have surveillance systems in the aisles. You are supervising the data running on your wiring harnesses. The combination of all of that will make your castle secure.
The same thinking needs to be applied on distributed systems in a car with 200 control units, a wiring harness and connectivity to the outside world. It’s this this type of thinking the engineers need.
Junko Yoshida: How do you train your engineers to understand security?
Lars Reger: They don’t have this on the study curriculum. So, we started training our guys ourselves. I have more than 3,000 engineers trained in a security school, as we call it. And hundreds of engineers on a self-built curriculum of a functional safety school. That has cost me a couple of hundred thousand.
It is regarded as being of a high enough quality standard that we have other companies, certification companies coming to help us and joining forces with us. And for the engineers, it’s great because they can put this on their CVs, enrich their own capabilities, plus they get a broader view.
And of course, then they can start talking about enabling chip security. The first question is what security do you need? With the house analogy, do you need to have a front door lock type of security or a kitchen / living room type of security, or do you want to protect your wine cellar? The point is, what are the security levels, and do I understand the system? And from there it’s then possible to fold this back into the specific requirements then scale it, using the right products from our portfolio.
Mixed mission profiles in the same silicon
Richard Quinnell: Is there anything you wish your customers knew before they came to you?
Lars Reger: The similarity between functional safety and security. What do I mean? What I am describing is going from a system risk assessment down to the component level. You need to ask what could go wrong in the system, on that level. Functional security is very much the same. You now bring in connectivity and ask what could go wrong on the level of my fridge, on the level of the connectivity box of my fridge, on the cooling system of my fridge and so on. In principle, you follow the same reasoning, but only a very few people in the industry really get that [similarity].
While we need to be refocused on safety and security, what I also see coming up is the mix of different capabilities in silicon. Emerging are what we call crossover microcontrollers in which you have a very tiny, very energy efficient microcontroller, and a big fat microprocessor sitting next to that on the same piece of silicon.
So, if you have a front door surveillance camera, the tiny little microcontroller is just heavy enough to run a lightweight artificial intelligence (AI). It can distinguish between a cat, a tree moving in the wind, a car passing by, or human movement. And then it wakes up the big system and the big system says, oh, that is my friend – open the door. Or this is the postman – I’ll inform Lars that the parcel has been delivered.Or it is this is a guy I’ve never seen before. So, take at least a couple of pictures and inform Lars that there is something strange going on.
This enables false alarms to be overcome in surveillance systems. In the case of automotive, you have a rear-view camera and your navigation system. These systems in one piece of silicon can, within a couple of milliseconds, wake up the microcontroller and immediately bring a picture of the rear view onto your system. You don’t overrun the kid behind your car. But it might take 20 seconds to boot up the big system for the rendering of the navigation. Who cares though? Let the navigation thing come up slowly. Your vital functions of the system are up within a split second. Hence the trend is that you can combine functionally safe stuff, easily see camera and your navigation system, and meet ASIL requirements in one piece of silicon.
And you have this in more and more silicon. This is computing at the edge with very, very different mission profiles on safety and security.
Give people the right toys to play and innovate
Nitin Dahad: So as a CTO, your job is to look at the future and look at what’s coming up in terms of both technologies and applications. How would you enable your successors to take on that kind of role?
Lars Reger: The one thing that I can do as a CTO is invite people to play with NXP. That is, if I would only have one sentence. That is the job that I have to do. Give the people the right Lego blocks, the right toys to play. You have 26,000 customers. And I have no clue in overseeing what type of innovations they are doing with our chips.
So, my successors will need one thing. They will need the ability to instill curiosity in the people that they talk to, the willingness to play with our stuff. And that is very much what I also see in the young generation – they are more easy-going. “Let’s program this little thing here and that little thing and then play with this and then it’s funny. And then I can share it and I get energy out of that.”
Richard Quinnell: We thank you very much for your time and vision insights.
The post Distributed Networks: Q&A with NXP CTO appeared first on EE Times Asia.
from EE Times Asia https://ift.tt/3e5hm9e
No comments:
Post a Comment
Please do not enter any spam link in the comment box.