CAN Newsletter December 2005
| Business | News - CANopen SIGs - J1939 Product Guide |
|---|---|
| Application | Proton beam medical machine - CANopen controls hospital beds - Siemens Medical uses CANopen - Philips Medical uses CANopen - Motion control in sausage casing machine - Automatic door system - Food production machine - Automotive devices production - Automation solution for adhesive melters - Furniture production - Natural wood production |
| Specification | X-ray dose measurement systems - Contrast media injectors |
| Device | HMIs - Datalogger - I/O for explosive areas - PC/104 - Debug interface - Sensors - PLC -Starter kit - Protective door - Tool - Inductive CAN enables contactless communication - Energy conservation controller - Interface S7/CAN - Strain sensor - PCI - Interface - Data acquisition - Safety controller - Inductive sensor - Flow rate, acceleration sensor - CAN switch characterization - Operator panels - CANopen systembus - NMT Master controller - Motion control - I/O modules - Doagnostic tool - ASi/CANopen gateway |
| Semiconductor | Blackfin 32-bit with CAN - 32-bit semiconductor news - IP core - Transceiver - Micro-controllers |
| Tool | CANopen development tool - Demo tools - Simulation - Calibration - NMT master |
CANopen networks in X-ray dose measurement systems
CAN in Automation released the CANopen device profile for dose measurement systems as CiA DSP 412-6. The DMS (dose measurement system) is located after the collimator in the X-ray beam and is used to measure the X-ray dose (rate) in an X-ray system. Besides the dose, the DMS measures also the dose area product, entrance/skin dose and the corresponding dose rates. The entrance/skin dose is the dose applied at the patient table. The DMS calculates it using the distances from focal point to metering chamber and patient table and/or from the dose area product at the metering chamber, using the irradiated area at the chamber plane also...
Monitoring and controlling contrast media injectors
In medical devices for computer-tomography or angiography, CANopen is used as embedded network. CiA’s CANopen SIG (Special Interest Group) Medical has defined profiles for medical add-on devices such as CMI (contrast media injectors) and ECG (electrocardiographs). These profiles in the CiA 425 series provide a high degree of plug-and-play capability. This means that the specification restricts the bit-rate to 250 kbit/s and defines five classes for the CMIs. Also the heartbeat producer and consumer times as well as some PRO turnaround times are specified in the profile. The class definition describes which objects are mandatory and which are optional. The NMT master functionality must be implemented in the medical diagnostic device. Part 1 of CiA 425 allows two different connectors (15-pin D-sub connector for devices that are just infrequently plugged, and 10-pin round connector for frequently plugged devices). Both connector types provide pins for a geographical addressing. With these pins the CANopen node-ID (16 to 46) is assigned to the injector device. The node-IDs 1 to 15 are limited to diagnostic devices. Of course, geographical addressing is not required for permanently connected devices. There are also some general recommendations regarding the total network length (100 m) and the accumulated stub length (25 m). The single stub length is recommended not to exceed 5 m...
CANopen communication controls hospital beds
Several years ago a design team was assembled to develop a new communication protocol for future hospital bed needs. The existing internal serial protocol technology was based on a popular standard, but tailored to the extent that it was manufacturer-specific. Engineering staff required to maintain the protocol was increasing. Updates to the standard had to be manually controlled to implement new features. The development tools and hardware were expensive and the development environment was difficult to migrate to new Windows operating systems. Training new engineers on the software and tools required internal resources due to the customization. After years of evolving previous designs, this team was able to start from a clean sheet of paper. This was the start of a new communication platform.
Patients in hospital beds would be amazed if they knew about the number of electronic modules that are required to deliver premium care for patients and improve caregiver effectiveness. The hospital environment has a diverse set of requirements: from long term stay facilities, medium acuity (med-surge) general short-term stay to critical care. For each environment, the complexity and number of electronic modules can vary up to 20 independent microprocessors communicating together.
Siemens Medical Solutions uses CAN and CANopen
In the early 1990s Siemens Medical Solutions, then known as Siemens Medizin-technik, was faced with an ever-growing demand for more functionality combined with an immense market pressure to reduce the cost of medical equipment. It became apparent that in order to reduce costs and still provide the required functionality it would be necessary to make a paradigm shift in the way medical equipment was built. The development engineers at Siemens looked to the automotive industry for guidance. At that time the CAN bus was beginning to make a great impact on the way cars were built. The CAN bus provided a robust and deterministic medium allowing decentralized embedded control components to communicate with each other. The fact that CAN was finding such fertile ground in the automotive industry also meant that CAN technology and components would be available at inexpensive prices. So perhaps CAN could solve the dilemma of providing a communication platform capable of catering for the increased functional complexity while also reducing equipment costs.
The Siemens engineers set to work. Concepts were designed and presented, advantages and disadvantages discussed. Finally it was decided that CAN would form the communication backbone of the next generation computed tomography systems.
Philips Medical Systems uses CANopen medical technology
The combination of complexity and time-to-market requirements of today’s medical equipment can only be met when the development of that equipment is based on a platform. Philips Medical Systems uses product line engineering as strategy to cope with the evolution of all kinds of product line family members. The success of a product line platform is determined by the chosen architecture and the external variability.
In the modern product line platform, the system is dominated by component architecture. Within the development activities for a product line, there is a clear distinction between component developers and system integrators. Component developers concentrate on the functionality and price/performance of a device. They must balance price/performance scalability, synergy between requirements of different systems that can use that component, and economy of scale. System integrators concentrate on the development of systems that supports a medical application domain. They use components as system buildings blocks, and parameterise and control these components to realise their typical application.
Medical systems are composed of components that are connected through interfaces. The interface is an abstract description of the internal functionality of the providing component. There may be several implementations of the same functionality. This is an important way to design for flexibility, and a mean to realise variability. Hence, a good and stable design of interfaces is crucial for allowing flexible configurations. As industrial data communication technology CAN has been used in medical systems for about 10 years, starting with CAL. CAN was chosen because of the features it offers, and its low interface cost price. CAN is used as component interface for non-time-critical commands, and status & event notification.
It is important to offer standardised and harmonised component interfaces and protocols, because then these components can be used in many systems. Standardisation becomes especially relevant to be able to incorporate standardized medical components from other vendors, and for OEM-selling of our own components. For component development CANopen is a logical step forward, since CANopen adds the application profile, the ‘what’ to the component interface, where CAL only defines the ‘how’. CANopen is therefore an enabler for standardization of component interfaces.
