iCon-L in medicine engineering
During hemodialysis (blood purification with the machine “artificial kidney”), the blood circulation is attached to an “artificial kidney”. This device is called hemodialysis machine and it is purifying the blood of a patient. The actual blood purification takes place in the dialyzer, the filter of the dialysis machine. To channel the blood through the hemodialyzer, the doctor places a catheter in a vain, similarly to taking blood. The blood to be purified will be pumped through this catheter and through the artificial kidney.
To make sure the dialysis machine works accurately, the dialyzer has to go through a reliable test. With the hemodialyzer analyzer, an inspection system has been developed, with which the test can be conducted. The analyzer works according to the DIN EN 1283 standard.
- Pressure holding test
- Leak test
- Measurement of the hydraulic permeability
- Determination of the
- Determination of the diffused permeability
- Determination of the sieving coefficient
With approx. 80 operating modes, 12 PID control circuits and more than 30 independent tests on credibility, the automation has very high demands regarding software engineering of the micro controls and especially the possibilities to watch the software behavior.
The whole system architecture is consequently customized on the 3 technological areas:
- Dialysate circulatory (DC)
- Blood circuit (BC)
- Providing the test media
For each circuit, an independent control with an independent software is provided. The controls are providing service and only obtain parameter and operating mode. The controls implement all necessary regulating and control tasks independently and only confirm the fulfillment of the operating mode.
The synchronization between the controls is performed on basis of the central operation mode administration.
|Development and production of a small batch series of an automatic inspection system for dialyzers
|IBP Medical GmbH
|Service provided by ProSign
|Implementation of the iCon-L runtime kernel as well as software technology consultation and support during development of the application software for the micro controls.
|3 independent controls LPC2468 (ARM7)
|Process data points
|approx. 50 I/O data points over specific I/O modules (RS485)
|- OPC interface to LabView over CAN bus
- communication management to the I/O modules programmed in iCon-L
|Size of the application
|- DC control 2537 FBs
- BC control 2235 FBs
- MSU controller 1573 FBs
- visualizing and parameter blocks were not counted
Systematically from the task to the program
Even though the development of the software takes much time and money, the value of software is mostly not seen like that. Mostly, the design of the electrical enclosure is more important, than on the design of the software. Especially when changing the software afterwards, the software, and here especially the changed documentation, is managed rather carelessly. You can minimize later carelessness by using a good basic design, as naturally it is harder for a human being to destroy a nice design, than making an already bad design worse. The software structure can fundamentally determine sustainability and permanent value of the software. You should always see the software as valuable goods, which has to be treated as carefully as material things.
Besides the basic value of the software, the software has to fulfill further demands in embedded systems.
- The software has to fulfill high standards regarding comprehensibility, testability and observability
- The software is embedded in very costly and valuable systems and is mostly very durable for that reason
- Because of the long durability, the software is often transferred to multiple development generations
- Because of the interaction with physical, technical processes, the online mode and error detection is very difficult and is not supported efficiently by classic methods for debugging.
- In contrary to pure software systems, the function of the software in embedded systems, especially with the close connection to physical, technical systems and their aging and wearing, the software is therefore constantly included in maintenance and servicing.
For the reasons stated before, the embedded software has to fulfill certain requirements.
- Basic software principles like modularity, top-down draft, structured analysis, hierarchy etc. have to be fulfilled.
- The software should have a highly self-documenting structure and has to clearly represent the context of the application.
- The software has to support observability during online mode and maintenance, which is customized on the requirement of the application.
In the present HDA 10 project, the functional specifications were ideal preconditions to apply the golden rule. The diagrams reflect the context of the application perfectly. Furthermore the diagrams support the application of the top-down draft procedure.