The term “Dedicated Systems” has now, after one year, started to find some measure of everyday usage among readers of this magazine. The term itself covers, nonetheless, a fair variety of system characteristics, each being fully or partially described as being embedded, and/or realtime, and/or fail-safe, and/or safety-critical.
The next step is now to find an adequate definition of the term "dedicated system", which will be meaningful yet effectively embrace of these types of system. My starting point was the following definition:

Dedicated Systems are systems where the functionality is once and for all tied up in the hardware and the software.

But after using this for a couple of months, I ended up feeling it just didn't cut the ice. Why? Because, if you think about emerging technologies like "smart devices" and "web appliances", it fails to give sufficient support to the notion that system functionality can be adapted via downloadable software - and therefore that parts of the hardware may be reprogrammed to change their functionality "on the fly".
Therefore, until we find something better - or until some new capabilities emerge which once again alter the landscape - we propose the following interim definition:

Dedicated Systems are systems where the total possible functionality is limited and tied up in the hardware and the software. This functionality may be partially or fully available. Software functionality may be downloadable and some of the hardware functionality may be  reprogrammable.

Capability to reprogram is a key factor in the success or failure of tomorrow's systems. There are different reasons for that.  Firstly, the degree of complexity is so high that it might be necessary to fix bugs, improve performance flows, and include requirements that were originally unforeseen or unsuspected - able to be captured a posteriori through actual use of the system, rather than a priori during the planning & design stages. Secondly, for business reasons, it might be of value “not to release” all functionality at once. Commercial strategy may call for users to be induced to pay for a new version of the product, in the form of extra functionality released or downloaded. Finally, the window of opportunity for getting new systems to market getting smaller all the time - to such an extent that sometimes you might not want to wait for a new (network) standard to be finished before you start producing and shipping systems. It's not hard to envisage that adapting the hardware to the finished standard may be achievable by reprogramming an FPGA segment of the system.

Of course, all these reprogrammable features are introducing a vital new requirement for these kinds of systems - and that is: security. History shows that someone, somewhere, will sooner or later try to crack the system - if only to "prove a point", and God forbid, with malevolence in mind - especially if you're behind the wheel of a car at the time. Security is therefore beginning to raise it's head as an emerging major issue in these systems. However, if we look to the availability of memory protection schemes, supported by RTOS - which is a key element for protection - then RTOS vendors - or your own design team, if you're "rolling your own" - should start applying serious effort to cracking this nut. Or perhaps we might put it the other way around and say, to making the nut so hard to crack that anyone tempted to try gives up before they start.
 
 
 

Dr Martin Timmerman
Contact

Dedicated Systems Magazine in general