We've got a similar problem. At present customers upload a single file (via a web page) for the software, plus a few small files for configuration. (And this file contains all the software running on the unit, including the RTOS, drivers etc.) That has proved to be within the capabilities of just about everyone.
Moving to the CM5 (or any other similar module) opens up a whole new can of worms, mostly because of the 'extra' facilities we want/need to provide.
Updating our own software could probably be achieved in the same way as before (although internally it may be more involved in terms of temporarily shutting down tasks and so on; currently a zipped file of software is extracted to, and run from, RAM, so we just replace the zipped file and reboot.) Although updates are infrequent; generally once a unit is commissioned, nothing changes.
For the CM5, the big issue is keeping the 'operating system' software up to date which, for some functions, could be essential. In particular security-related matters.
Some of our units may not have a network connection at all; as far as I know all others sit on an internal system or engineering network with zero access to the internet (sometimes even airgapped, I think; as a minimum heavily locked down via a firewall).
It does appear that in some companies (usually the larger ones) the approach to security is that everything needs to be secured to the same standards as a desktop PC or file server which has internet access; no consideration of the operating environment. (And the average hacker probably wouldn't understand how to cause damage via our equiment, much less turn it to good use! There's no sensitive information to extract; 'just' the possibility of sending inappropriate commands to cause reputational or physical damage).
There's no real possibility of replacing a physical memory within the unit (they are mostly rack mounted, sometimes on unmanned sites); so we really need a network-based solution, with recovery mechanisms.
Biggest issue we've found so far is managing the certificates associated with secure/encrypted communication. Still looking into this, but without internet access it seems that this could be tricky, especially with the move to shorten the lifetime of certificates. And the process needs to be automated, as well as allowing for equipment which has been switched off for a few months or more.
It's an interesting transition; for the first iteration of these units (30 years ago) we wrote 100% of the software. The second iteration (15 years ago) used a lot of software provided by the SOM module manufacturer (and very reliable, it is), especially to handle networking and the like. In this this 3rd iteration our own software, although essential to the end use, will be a small fraction of the total software running on the unit (quite possibly <1% of total file size) and we're totally reliant on third party software for everything to hang together.
Moving to the CM5 (or any other similar module) opens up a whole new can of worms, mostly because of the 'extra' facilities we want/need to provide.
Updating our own software could probably be achieved in the same way as before (although internally it may be more involved in terms of temporarily shutting down tasks and so on; currently a zipped file of software is extracted to, and run from, RAM, so we just replace the zipped file and reboot.) Although updates are infrequent; generally once a unit is commissioned, nothing changes.
For the CM5, the big issue is keeping the 'operating system' software up to date which, for some functions, could be essential. In particular security-related matters.
Some of our units may not have a network connection at all; as far as I know all others sit on an internal system or engineering network with zero access to the internet (sometimes even airgapped, I think; as a minimum heavily locked down via a firewall).
It does appear that in some companies (usually the larger ones) the approach to security is that everything needs to be secured to the same standards as a desktop PC or file server which has internet access; no consideration of the operating environment. (And the average hacker probably wouldn't understand how to cause damage via our equiment, much less turn it to good use! There's no sensitive information to extract; 'just' the possibility of sending inappropriate commands to cause reputational or physical damage).
There's no real possibility of replacing a physical memory within the unit (they are mostly rack mounted, sometimes on unmanned sites); so we really need a network-based solution, with recovery mechanisms.
Biggest issue we've found so far is managing the certificates associated with secure/encrypted communication. Still looking into this, but without internet access it seems that this could be tricky, especially with the move to shorten the lifetime of certificates. And the process needs to be automated, as well as allowing for equipment which has been switched off for a few months or more.
It's an interesting transition; for the first iteration of these units (30 years ago) we wrote 100% of the software. The second iteration (15 years ago) used a lot of software provided by the SOM module manufacturer (and very reliable, it is), especially to handle networking and the like. In this this 3rd iteration our own software, although essential to the end use, will be a small fraction of the total software running on the unit (quite possibly <1% of total file size) and we're totally reliant on third party software for everything to hang together.
Statistics: Posted by stevend — Sun Nov 30, 2025 9:43 am