The process of Embedded system development should be familiar. At a really high level the steps involved in a project should be the same. You gather business requirements, analyze how to translate them into software, run a testing phase and then do it all again.
Yet these familiar coding and project management skills must adapt to some new and interesting challenges, foremost among which is the real time capabilities of many embedded operating systems. Embedded operating systems need very high reliability. They must always be predictable: the system should guarantee you will get a response in a certain amount of time.
The qualities are important because Embedded systems are often deployed in environments where milliseconds can literally be the difference between life and death. -A real time OS can never fail. For things like avionics controls the result of failure is catastrophic.
A project for Embedded system is to control a freight company's conveyor belts and package-sorting systems where the stakes were lower, but requirements are just as sensitive.
Only microseconds between when a barcode on a package was scanned and the embedded device issued the instruction about which chute it should go down. If you are writing that kind of software you need to know the operating system will send the message to the conveyor belt in time, because if it does not you have a problem.
Programmers for Embedded systems must come to grips with these issues, and the fact that addressing them requires work to understand how embedded OSes interface with the hardware in an embedded device.
In Embedded system development there is quite a significant blurring of the line - you could argue there is no line between hardware and software. This idea has coded extensively in the embedded and enterprise worlds. With Embedded system you are much 'closer to the metal'. You are dealing with the pins on the chips and clock cycles and interrupts.
No comments:
Post a Comment