programs driving external hardware, considerations ?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: programs driving external hardware, considerations ?
Note: comp.arch.embedded added.


Quoted text here. Click to load it

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

1. Use a closed system running an RTOS if timing is important.
2. Think safety first, if that is an issue for your application.  Have a
fallback if the processor itself fails.
3. 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.
4. Consider implementing in layers, where the bottom layer implements
simple controls with adequate safety constraints, driven by higher level
logic.
5. 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.
6. Create test cases which exercise the possible error conditions.  This
will probably involve manual testing for external components.
7. Check out comp.arch.embedded for issues involving realtime
applications and hardware control.

Thad

Site Timeline