Representative End User Clients
Representative Automation Clients
Representative Software Clients
What strikes me personally right now in researching the industrial IoT is a need I see cutting across many segments – that need is for breakthroughs in the deployment and support for embedded systems at scale. Notice that I said deployment and support, not development.
One difficulty here is that different parts of the Industrial IoT will use completely different vocabularies to address this need, and so besides the people involved never crossing paths in real life, the programs, projects, and developments that are performed in different industries may well occur in a “silo” albeit sometimes a very big silo, such as the global automotive industry.
Let me touch on just two of the many different examples to illustrate this thesis: 1) autonomous vehicles 2) process automation. In each of these areas there are major IoT-related initiatives underway right now.
Autonomous Vehicles
The challenges in developing in-vehicle systems to support greater vehicle autonomy are daunting. The parallels with industrial automation are striking. Vehicles have historically been networked using low cost device networks (CAN and LIN). These device networks will persist in the future but will be supplemented by a 1GB automotive Ethernet (IEEE 802.3bp). Some of the many new compute functions will end up running in an onboard vehicle server.
Since 2003 global automotive manufacturers have collaborated on embedded electronic control unit (ECU) software via the AUTOSAR organization. AUTOSAR stands for “Automotive Open Systems Architecture” and AUTOSAR works to standardize in-vehicle systems. This year AUTOSAR released a new standard “adaptive platform” -- a Linux system with SOA services for multiple applications (see figure). This contrasts with older vehicle embedded systems which had static (non-adaptive) communications architectures.
The new AUTOSAR is the first standardized automotive platform that supports over-the-air (OTA) software updates. So automotive manufacturers could use it to do anything from an ECU update to installing a new application, at least in theory. This is one answer to managing the car’s software as if it was a big, mobile embedded system, which is what cars are truly becoming.
This is just scratching the surface, as there’s much more going on with embedded software in the automotive industry today. But the point here is that the new platform is capable of being updated remotely for the life of the vehicle.
Process Automation
The Open Process Automation Forum is working to define a standards-based architecture to perform the automation functions of today’s proprietary DCS controllers and I/O systems. Their objective is to enable end users (for example, chemical plants) to use both hardware and software from any number of suppliers rather than from their DCS supplier (and that supplier’s ecosystem) alone.
In order to do this, OPA Forum members will have to agree on how they will deploy and update the software and applications on these controllers and I/O systems (see figure). Typically these systems have a service life of 10-20 years (like a car) with occasional software updates that are performed locally by the DCS supplier’s service organization. This OPA effort began in earnest only in 2017, so unlike AUTOSAR its first deliverables are still a way off. You can read much more about the status of the OPA here.
Other Areas
Some other areas where there are similar efforts to manage embedded are going on now? There are so many I can’t keep up, but here here some examples: In edge computing and edge analytics the Linux Foundation’s EdgeX Foundry is just one example. Container software for edge devices is the point of the updatable resinos operating system, and the Nerves Project is an effort to modernize deployment for basic of embedded devices. There are many others, some of which may prove to be far more important than these.
In short, the autonomous car and the IoT (both industrial and consumer) are spawning many solutions to the chronic problem of long term deployment and support for embedded systems. These efforts make me much more optimistic about the future of the IIoT. In some future imaginary world just as in Lake Wobegon, “all the women are strong, all the men are good looking, all the children are above average” ...and all the embedded systems will update themselves. That sounds great.
One difficulty here is that different parts of the Industrial IoT will use completely different vocabularies to address this need, and so besides the people involved never crossing paths in real life, the programs, projects, and developments that are performed in different industries may well occur in a “silo” albeit sometimes a very big silo, such as the global automotive industry.
Let me touch on just two of the many different examples to illustrate this thesis: 1) autonomous vehicles 2) process automation. In each of these areas there are major IoT-related initiatives underway right now.
Autonomous Vehicles
The challenges in developing in-vehicle systems to support greater vehicle autonomy are daunting. The parallels with industrial automation are striking. Vehicles have historically been networked using low cost device networks (CAN and LIN). These device networks will persist in the future but will be supplemented by a 1GB automotive Ethernet (IEEE 802.3bp). Some of the many new compute functions will end up running in an onboard vehicle server.
Since 2003 global automotive manufacturers have collaborated on embedded electronic control unit (ECU) software via the AUTOSAR organization. AUTOSAR stands for “Automotive Open Systems Architecture” and AUTOSAR works to standardize in-vehicle systems. This year AUTOSAR released a new standard “adaptive platform” -- a Linux system with SOA services for multiple applications (see figure). This contrasts with older vehicle embedded systems which had static (non-adaptive) communications architectures.
The new AUTOSAR is the first standardized automotive platform that supports over-the-air (OTA) software updates. So automotive manufacturers could use it to do anything from an ECU update to installing a new application, at least in theory. This is one answer to managing the car’s software as if it was a big, mobile embedded system, which is what cars are truly becoming.
This is just scratching the surface, as there’s much more going on with embedded software in the automotive industry today. But the point here is that the new platform is capable of being updated remotely for the life of the vehicle.
Process Automation
The Open Process Automation Forum is working to define a standards-based architecture to perform the automation functions of today’s proprietary DCS controllers and I/O systems. Their objective is to enable end users (for example, chemical plants) to use both hardware and software from any number of suppliers rather than from their DCS supplier (and that supplier’s ecosystem) alone.
In order to do this, OPA Forum members will have to agree on how they will deploy and update the software and applications on these controllers and I/O systems (see figure). Typically these systems have a service life of 10-20 years (like a car) with occasional software updates that are performed locally by the DCS supplier’s service organization. This OPA effort began in earnest only in 2017, so unlike AUTOSAR its first deliverables are still a way off. You can read much more about the status of the OPA here.
Other Areas
Some other areas where there are similar efforts to manage embedded are going on now? There are so many I can’t keep up, but here here some examples: In edge computing and edge analytics the Linux Foundation’s EdgeX Foundry is just one example. Container software for edge devices is the point of the updatable resinos operating system, and the Nerves Project is an effort to modernize deployment for basic of embedded devices. There are many others, some of which may prove to be far more important than these.
In short, the autonomous car and the IoT (both industrial and consumer) are spawning many solutions to the chronic problem of long term deployment and support for embedded systems. These efforts make me much more optimistic about the future of the IIoT. In some future imaginary world just as in Lake Wobegon, “all the women are strong, all the men are good looking, all the children are above average” ...and all the embedded systems will update themselves. That sounds great.