Industrial Linux
Now it's real(ly) time!
Industrial Linux
Now it's real(ly) time!
Embedded devices, whether controllers or small IIoT devices, which have an update system, should be able to be updated with current software versions without human intervention. At the same time, their status (last software version, useful life, memory consumption, temperature, etc.) should be known at all times. And it should also be possible to predict maintenance from the available data. All these functions are offered by a modern device management and update system.
| What should an update system be able to perform? |
A device is required to be securely authenticated before it may dock with the update server. Likewise, the device must be certain that it has docked to the correct server.
There are different procedures to accomplish this, which depend on the capability of the end device. In the simplest case, this can be a unique identity of the device, a UUID (universal unique identity). This is stored securely in the device during production. It is then brought to the management server by a manual action (exchange of data).
In addition to such simple (and therefore easily manipulated) approaches, there are also much more secure procedures (see also Onboarding / Zero Touch Onboarding) such as proof of identity through certificates. In this case, a continuous chain of trustworthy certificates is stored on the device, and such a certificate is made known to the update server. The update server in turn has a list of trustworthy certificate sources (CA - certificate authorities) and checks the offered certificate against it. If the check is positive, the device is accepted and stored with its attributes (name, location, etc.).
The main purpose of an update server is to distribute an update via an Internet interface. The preferred procedure will be for a device to check whether an update is available. If so, it will download the update file.
The update server must also be able to deal with devices that have not been active in the network for a long time, which may mean that older updates must first be applied before the latest one is implemented.
It should be possible to arrange devices into groups, whereby the criteria for the selection should be user-definable. Groups can, for example, describe devices in the same geographical region, but also devices with the same hardware status, the same product name or similar.
A group should then receive an update automatically - provided this has been configured.
It is advisable if only a small subgroup receives your update first, and only if it is successful (e.g. if 100 % of the updates were successful) do the remaining devices automatically receive your update. This campaign capability significantly increases update quality in the field.
It is also helpful if an update can be rolled out to one single device only. This is useful for testing, but also for solving problems that are found only on a single unit.
If a device does not update - for whatever reason - the status of the device must indicate this and enable the update to be done later on.
After an update, a unit must send a feedback message describing the status of the update. This is the only way to evaluate the success of the update.
This channel can also be used for optional monitoring of the units. Here, relevant system parameters are continuously transmitted to the server and stored there.
The evaluation of this data can take place locally in the server or remotely in a maintenance server (cloud), be displayed graphically and be the basis for predictive maintenance.
Monitoring data could be:
There are various ways to get this data from the device to the server. A lot depends on the location, etc. Our standard solution is based on OPC UA and uses its capabilities. We are happy to adapt our approach to your specific requirements.