programs driving external hardware, considerations ?

Hi Although i know what i'm doing, as i haven't got much experience i thought it would be good to get other peoples views. I'm writing a commercial program that will drive and read from external hardware, including a servo motor, LVDT units, and a PLC. There seems to be alot of complexity because of the hardware. Because of this, i'm using a state pattern, to drive my software. My notes from uni have allerted me to the necessity of making a program 'robust', and able to 'take whatever is thrown at it', and 'gracefully recover'. I get the impression that this means i should be considering all kinds of possible unexpected situations, or exceptions. For example, a user might pull out a lead, and, i was thinking, my program should detect this if possible and report. eg if the PLC lead is not plugged in, the program should report with an error message like 'check your plc line' etc. At the very least the program should not end up in a non-usable state, but the user should be able to interact and get it moving again. Am I going about this correctly, thinking through all kinds of possible exceptions and making sure the program wont end up in a non usable state? Perhaps someone who has done these kinds of programs (programs interacting with hardware) may have something useful to share? It's my first commercial program, and there is no one to get expert advice from.

thanks Gavran

Those are good considerations. Here are a few thoughts that might help

Use a closed system running an RTOS if timing is important.
Think safety first, if that is an issue for your application. Have a fallback if the processor itself fails.
Create a detailed design and operators' manual which explain the operation of the system clearly. This helps you, as the implementor, as well as the users and other engineers. Update as needed to keep them current. Plan for field upgrades.
Consider implementing in layers, where the bottom layer implements simple controls with adequate safety constraints, driven by higher level logic.
Give the user insight into what is happening during normal, as well as abnormal operation. Make the interface as intuitive as possible. Implement logging if the system is complex.
Create test cases which exercise the possible error conditions. This will probably involve manual testing for external components.
Check out comp.arch.embedded for issues involving realtime applications and hardware control.

Thad