I would like to incorporate an Arduino within a new burglar alarm. The Arduino will serve as a communications module monitoring the state of the system, squawking over ip. For the burglar alarm types, this will be an ersatz commIP module. It needs to be reliable as the emergency services may be called depending on it's output.
Is an Arduino suitable for this role? I have little experience of them, or their reliability. Embedded systems are pretty reliable, as you'd expect of the computer system within an airliner /nuclear power plant.
I'm not immediately concerned with programming bugs. That's common to all software. My issues are:
Will the Arduino lock up?
Should my software be hard interrupt driven only?
Does it need an independent hardware watchdog circuit?
Is it temperature tolerant?
How resistant is it to a thunderstorm?
Are there specific EMI shielding requirements?
Would you have an Arduino controlling your grandmother's life support system?
I'd be grateful to get a perspective as the the viability of Arduino usage for real world embedded systems. I realise that this is a broad topic, but opinions /suggestions /rebukes would be welcome
Will the Arduino lock up?
Yes, any CMOS device can experience latch-up.
It can be caused by lack of proper power supply bypass capacitors or a cosmic ray (which can go through shielding).
The watchdog timer will generally not clear a latch-up, power needs to be removed and then reapplied to the chip.
The electric and magnetic field near a lightning strike can cause disturbances that also trigger latch-up (without it even hitting the power system).
EMI shielding is the best option, but it most likely will not stop every cause of latch-up.
The most likely cause of a lock-up is my software that traps the microcontroller in a little loop that I did not intend. I am sure as hell not going to write the software for anyone's life support, but with shielding a system with redundant ATmega328 might be an option. Arduino is not a redundant design it is for learning.
To give an example of how much I don't trust my own software I did my reflow control by reading an EEPROM value every two seconds and then applying it as the ovens PWM for that time. That way I could run through the profile and test every operation that would happen, no hidden lock-up that could burn down my house (except latch-up... well that sucks).
Ron, your oven scenario seems even more serious than my alarm. At least the police aren't going to burn my house down. If latch up is an issue, why didn't you incorporate a hardware watchdog for peace of mind? Something like a Maxim DS1232? I've used these before with a Basic STAMP.
Does it need an independent hardware watchdog circuit?
Is it temperature tolerant?
How resistant is it to a thunderstorm?
Are there specific EMI shielding requirements?
You should treat the Arduino the same way you'd treat a bare microcontroller chip. An Arduino board is little more than a breakout for the AVR, and adds no significant protection from external badness. Nor does it include any overly sensitive components that would tend to increase susceptibility to such badness.
You're aware that you can design a board around one of the Arduino microcontrollers and use the Arduino environment to program it, even if your board does not contain an actual Arduino "module" of any kind, right? That's usually the professional "direction." The only reason to use a module is convenience and lack of design skills or facilities...
Would you have an Arduino controlling your grandmother's life support system?[/li][/list]
This is explicitly disallowed by Atmel, and probably by all of the other manufacturers of components on the board, without special permission:
Atmel products are not designed for and will not be used in connection with any applications where the failure of such products would reasonably be expected to result in significant personal injury or death (“Safety-Critical Applications”) without an Atmel officer's specific written consent. Safety-Critical Applications include, without limitation, life support devices and systems,...
This is "standard." I assume that getting such consent involves convincing Atmel's legal department that YOU have enough insurance and legal expertise to ensure that Atmel is not held accountable for your bugs, rather than technical issues. That's why medical electronics tend to be outdated and very expensive - legal expenses.
The hardware watchdog needs to remove power from the MCU that has suffered a latch-up. I worked for a while with telecom equipment and seem to recall they sent a heartbeat signal between two computers, but only one was acting as the live server. When the backup stopped getting a heartbeat it would take over as the live server and had connections to control a power cycle of the other (though at the time that seemed odd). Wonder if I could be clever enough to figure out how to do something like that with two ATmega328... that idea will need some time to fester.
Ron, your two server idea sounds good and might actually be simpler than you think...
Rather than a live server and backup server, have two Arduinos. They're twins with all the same I/O and code. Each has a pin output that toggles the power to the other. Just a plain FET. Then pass a token back and forth between the two over a serial port. The token might just be "Hello - I'm a token." If you have the token, you process stuff for a bit and hand the token back. If you don't receive the token for 10 seconds, power cycle the other Arduino and wait again.
Complication: If your code requires maintaining state, you pass that state as part of the token. This is effectively what is called replication in the computer world. It's a tried and tested technique that has been proven to work with the largest computer systems, not just small embedded stuff.
You're aware that you can design a board around one of the Arduino micro controllers and use the Arduino environment to program it, even if your board does not contain an actual Arduino "module" of any kind, right? That's usually the professional "direction." The only reason to use a module is convenience and lack of design skills or facilities...
This is the crux of my question. Grandmother issues aside, are you suggesting that an Arduino “module” is unsuitable for embedded use?
(UPDATE: This was for post #7 not looked at #10 yet)
That is an interesting idea, the reflow program uses a state for iterating through the EEPROM, and for preventing an overflow of the serial buffer. It was done with the command processor I have been tinkering with. I guess the command and both states would need to be replicated, but that is getting complicated. I use the UART for data logging while figuring out what settings to use for PWM of the oven. So perhaps I2C, SPI, or something else could be used to pass the token. It is an avr-libc program (C not C++), but I'll link to it anyway.
(power glitch: see post #9)
In the telecom world, the redundant computers also had redundant power supply systems feeding them. So you can pull a plug and nothing will stop, and even replace the power supply. You can pull one of the computers (rack mount blades) and replace it without much more than a transfer hickup (TCP/IP guarantees transfer so I am guessing it plays a role in the replication token stuff, nice I am making a wild guess that sounds right). I am thinking that a pin that could be used to kill power to the onboard CMOS might be a step in the direction to doing a redundant system (Arduino has an unused pin near its power pins). Redundant power at the Arduino scale may be as simple as using a few resettable fuses and diodes to or into the power inputs.
Or, go for the Maxim chip again this time controlling either both Arduinos, or two Maxims, one for each Arduino. Power supervision is one of the Maxim's main features. From it's data sheet:-
Holds microprocessor in check during power
transients
Automatically restarts microprocessor after
power failure
Monitors pushbutton for external override
Accurate 5% or 10% microprocessor power
supply monitoring
Arduino A waits 1 second at startup and then sends token. Arduino B waits 2 seconds at startup to receive token. Just a matter of getting the time offsets correct. Then they're off...
P.S. If you involve Maxims though, you might well then wonder at the benefits of 2 Arduinos. Personally, I would go with the one + hardware watchdog as that cuts out the replication. Rolling your own replication is probably tricky (as you suspect). In my quick research, I think that this latter scenario is more prevalent with embedded systems.
are you suggesting that an Arduino "module" is unsuitable for embedded use?
I'm claiming that it has no significant advantages over using a bare chip. If you believe that a microcontroller is unsuitable for embedded use, then using an Arduino instead is no help. If you believe that a microcontroller IS suitable, I don't see any reason that an Arduino Module wouldn't be. (Aside from, you know, the cheap modules whose schematic is unavailable, whose supply chain is unknown, and whose design and parts list variable...)
The talk of avoiding and correcting latchup seems ... misplaced. Very few industrial systems include that sort of circuitry, and a typical "burglar alarm" would be better of spending LESS time worrying about edge electrical issues, and more time worrying about being smashed with a crowbar...
So westfw, you're suggesting that an Arduino's suitable to stick in the attic for a year and it'll keep running without needing a reboot? That's exactly what I was hoping for
an Arduino's suitable to stick in the attic for a year and it'll keep running without needing a reboot?
Yes. Depending on how much lightning you get, and how stable your power is, and stuff like that.
It would make me nervous to do this without ANY human oversight, but I wouldn't expect it to fail, either.
A burglar alarm is a fine example; every time you activate or deactivate it, you're effectively doing a systems check, and if it doesn't respond as expected, you go and check why not.
