Control and Automation
Embedded Systems have tranditionally had a strong role in industrial control and automation. While recently this market has faded from view as the more 'exciting' consumer electronic gadget market has captured hearts and minds, it is the traditional embedded system which runs our washing machine, keeps our power stations generating and ensures that the cyllinders in our car engines fire in a smooth sequence.
As control and automation systems become more sophisticated they are becoming more connected. IP networking, cellular connections and even WiFi are appearing in these systems, joining the more tradition serial and cabled communications methods. These new options have more demanding protocol requirements, which is steering a move away from 'crappy' little 8-bit micros towards 32-bit architectures such as ARM. ARM chips are able to run a full TCP/IP stack, a Linux kernel and provide access to large amounts of non-volative storage, while still retaining the small, low-cost features of lower-end systems.
Given the larger amount of integration required on these modern systems, thoughts turn to development time and in particular, the time involved in testing and verification. Unlike desktop PCs where users expect a crash every now and then, a system crash can be catestrophic in an automation environment. It might cause loss or spoling of product, a reduction in product value, machine failure or even loss of human life. For these reasons testing of controll and automation embedded system is often half of the project investment. Devices are often designed with fail-over features such that another unit can transparently continue the job if one unit fails. Sometimes failure modes are examined to determine what might happen in a failure and how it might be detected and the results mitigated.
Unfortunately, the demands of testing and the increasing sophistication / complexity are pulling in opposite directions. Engineers are nervous of 32-bit chips with megabytes of third party software and a rather loose approach to interrupt latency. Nevertheless, as features are demanded they must be implemented and the challenges must be met head on.
Bluewater Systems Approach
Bluewater Systems has has used a number of RTOSs in various projects over the years. More recently our expertise has turned to creating reliable real-time systems using full Operating Systems like Linux and even Windows CE.
Many of the criticisms of Linux, for example (complexity, interrupt latency, memory usage and OS overhead) which applied 5-10 years ago have been addressed in later kernels. In our experience a 200MHz ARM9 system can be in and out of an interrupt in 4-5 microseconds. If faster performance is required, ARM's Fast Interrupt (FIQ) can be employed in special cases to provide servicing response of around 100ns. While Linux is not going to take over from the likes of Integrity OS anytime soon, for many many applications Linux can do the job, and offers other benefits to seal the deal.
Product Showcase (Mackerel)
A New Zealand company approached Bluewater Systems to develop a card access controller board with Gigabit Ethernet, tamper detect, internal storage, RS485, USB, an encryption chip and battery backup, among other features. The system included no display and was purely an embedded platform, hidden from view.
Due to the skills of its existing software engineers, the customer required that Windows CE be brought up on the board (in headless configuration). Bluewater Systems created a suitable BSP for the chosen ARM9 chip, along with drivers for all the peripherals. An innovative watchdog-based system provided for replacing the OS (if it corrupted itself) with a known-good version. This, along with other initiatives, provided a reliable platform for the customer which has been successful in the market.
