Case Studies

The following case studies give some examples of WareWorks design capabilities:

1. Environmental Data Logging.
2. Transit Monitoring.
3. Medical Monitoring and Control.

Please note that in some cases design done by WareWorks on different projects has been combined into a single representative study in order to protect client confidentiality.

Case Study – Environmental Data Logging

Design Brief:
A system to measure & record the moisture content in the frames of timber buildings:

• Multiple battery powered Slave units logging data at regular intervals.
• Each Slave periodically uploading its data to a mains powered Master unit via low power radio link.
• The Master unit uploading its data to a laptop PC on a yearly basis via high-speed serial link.

Design Considerations:
The design had to meet the following considerations:

• This was a medium to high volume product so cost was a major consideration.
• A real time clock was a requirement for time stamping of data.
• Very low power consumption was essential for the battery powered Slaves.
• Slave data storage had to be non-volatile.
• Master data storage had to be non-volatile & capable of storing the data from multiple slaves over a long time period.
• The firmware was to be written in embedded C in a modular fashion so that it could be re-used in future projects, possibly on different processors.

Design Implementation:

• An 8-bit NEC 78K0 microcontroller was selected for the Slave units:
• Low power modes.
• Highly cost effective.
• Integral real time clock (eliminating need for external IC).
  
  
• An I2C serial E2PROM was selected for Slave data storage:
  • Highly cost effective.
  • Minimal I/O overhead.
  • Available in a range of memory sizes allowing the Master data capacity to be flexible.
    
    
• An SPI serial Data Flash was selected for Master data storage:
  • Highly cost effective (in terms of capacity).
  • Minimal I/O overhead.
  • - Available in a range of memory sizes allowing the Master data capacity to be flexible.
    
    
• An FSK Transceiver IC was selected as the basis for the radio link:
• Minimal feature set (increased design time traded for lower unit cost).
• 433MHz unlicensed band.
  
  
• It was noted that the Slave microcontroller was also suitable for the Master resulting in a high degree of commonality:
  • A single PCB for both Master & Slave with selective population according to function.
  • A high degree of firmware re-use between Master & Slave.

Conclusion:
The project was deemed highly successful:

• The system passed all the Client acceptance tests with flying colours.
• The implementation fulfilled the design brief & met or exceeded all the design considerations.
• The Client was able to re-use much of the firmware in other projects with minimal support from WareWorks.

BACK TO TOP

Case Study – Transit Monitoring

Design Brief:
A system to monitor the conditions subjected to goods in transit:

• Temperature, humidity & acceleration.
• Small size to facilitate concealment.
• Battery powered.
• Non-volatile data storage.
• User configurable parameters.

Design Considerations:

• This was a high volume product so cost was a major consideration.
• A real time clock was a requirement for time stamping of data.
• Battery power made very low power consumption essential.
• Temperature & humidity change slowly with time & can thus be recorded at regular intervals.
• To preserve battery life acceleration is only monitored for a period following a significant shock, however during this period a data-recording rate of up to 2kHz was required.

Design Implementation:

• Selection of a suitable microcontroller was a major consideration:
  • The key requirements were as follows:
    • Low power modes.
    • Adequate performance for high-speed data recording.
    • Highly cost effective.
      
  • Initially a 16-bit TI TMS430 was selected to ensure the 2kHz data-recording requirement could be met.
  • However the TI part was too expensive so an 8-bit NEC 78K0 microcontroller was chosen although it was acknowledged that the firmware would have to be highly optimised to achieve the target performance.
    
    
• An SPI serial Data Flash was selected for non-volatile data storage:
  • Double buffered for high write rates.
  • Highly cost effective (in terms of capacity).
  • Minimal I/O overhead.
  • Available in a range of memory sizes allowing the data capacity to be flexible.
    
    
• User configuration was provided by an intuitive, menu-driven interface via an RS232 link to a Terminal application on a host PC. Configurable parameters included:
  • Temperature sampling rate.
  • Humidity sampling rate.
  • Acceleration sampling threshold.
  • Acceleration sampling rate.
  • Acceleration sampling period.
  • Etc.

Conclusion:
The project was deemed a complete success:

• Additional design work was required to achieve the required sampling rate with an 8-bit processor but this was more than offset by the reduction in unit cost.
• The implementation fulfilled the design brief & met or exceeded all the design considerations.
• The unit passed the acceptance tests without problem.

BACK TO TOP

Case Study – Medical Monitoring and Control

Introduction
The medical instrumentation industry largely consists of pneumatic, micro-fluidic and electro-mechanical equipment. Today's global marketplace necessitates that such equipment be cost-effective, feature-rich and able to integrate with the IT infrastructure. These requirements are met by the combining of software control and digital signal processing (DSP).

Software control provides some well-known advantages:

• Flexibility of operation, richness of marketable features.
• More adaptable to changing conditions, e.g. programmable or self-learning input filters.
• Easier testing, simulation and debugging.
• Replacement of redundant (and often expensive) mechanical interlock components.

.WareWorks understands the problems that can occur when traditional pneumatic and elecro-mechanical systems are replaced or augmented by software. Designing in reliability and the means to predict the behaviour of a system under all normal working conditions and failure modes are most essential aspects of medical equipment design.

Example #1 - Safe Software

Design Brief
Take for example a system that delivers anaesthetic to a patient. The anaesthetic must be mixed with other gases and delivered at concentrations determined by the anaesthetist. The concentration setting may be selected by a variety of input devices, e.g. rotary wheel, push buttons, touch-screen, etc..

Design Considerations
Regardless of the user-input device, look and feel of the system, the software designers must primarily consider:

• Maximum and minimum safe operating concentration and dosage for the anaesthetic selected. Too much anaesthetic can induce a coma and too little may leave the patient paralysed but still conscious to pain.
• Fail-safe feedback of the anaesthetic concentration.
• Feedback on all safety-critical components, including self-diagnostics of the software.
• Audible and visible alarms to indicate all abnormal conditions.
• Compensation for environmental conditions such as atmospheric pressure and temperature.
• Fail-safe condition in the event of power-loss.
• Proof of a safe design by providing the documentation and test plan to published medical standards such as EN46001, EN60601, etc.

Conclusion
Only when the above issues have been satisfactorily dealt with by the hardware and software design can the engineers proceed to the user interface and feature list.

Example #2 - Sophistication Versus Intrinsic Safety

Design Brief
Consider a ventilator that is required to deliver oxygen to a patient using a standard bellows and absorber arrangement. Two proportional valves control flow and pressure during the inspiration and expiration cycles. This system will require mass-flow and pressure sensors to continually monitor conditions at the patient airway and provide feedback for the proportional valves.

Design Considerations
A safety analysis of the rudimentary design will highlight issues, a few of which are listed below:

• If the inspiratory valve fails in the open position an over-delivery will occur.
• If the mass-flow sensor in the expiratory limb fails, the ventilator will not detect the expiratory phase.
• If the expiratory valve fails in the closed position the patient will be unable to spontaneously exhale.

The software, making appropriate measurements, can detect all the above conditions. But, this assumes that the engineers have created foolproof software algorithms. Rather than totally relying on "clever" solutions - a commonplace occurrence these days - the inclusion of simple pressure-relief valves provide a final safety net for potentially hazardous conditions.

Conclusion
The software’s “responsibilities” are downgraded to monitoring that the safety valve has released, and does not have direct control of the valve. This is a relatively simple and therefore safer way of operating, requiring the software to sound an alarm and place the ventilator in a fail-safe inoperable condition. The finesse in the software design is in the prediction of dangerous conditions before the safety valves operate, thus allowing the anaesthetist to take appropriate measures.

.WareWorks is committed to the development of intrinsically safe and appropriate solutions for the medical industry. We have direct experience of gaseous and liquid flow servo control systems, proportional valve control, touch-screen interfaces and digital filtering. We offer solutions in embedded C and Forth for a variety of microprocessors and microcontrollers.

BACK TO TOP