Transcription
Intelligent Medical InstrumentsZoltan Papp, Gabor Peceli, Balazs Bago, and Bela PatakiDepartment of Measurement and Instrument EngineeringTechnical University of Budapest, HungaryOWADAYS, the designers of computerized medical instruments attempt t o extend the performance of themeasuring systems w i t h data processing capabilities towardsintelligent reactions. These intelligent instruments can help inmonitoring, in measurement supervision, and in makingdiagnoses. This paper, based on the authors' experiences inthe development of intelligent EEG recorders and analyzers,introduces those system design methods that can contributet o the resolution of the rather complex requirements in thefield of medical instrumentation. These requirements involvethe problems of:Efficient implementation of conventional data processingalgorithmsEfficient implementation of knowledge-based data processing algorithmsEvent-driven real-time operationIntegration of problem-oriented user-friendly user interface, andThe interactions of the above elements.In this paper, both conceptional and implementational aspects are investigated and illustrated by some prototypingexamples.NFUNCTIONAL AND IMPLEMENTATIONAL EXPERTISEIn order t o perform successful measurements, detailedknowledge of the specific application field and the particularmeasurement methods are prerequisite. To develop efficientmeasuring instruments of any kind, knowledge of the user'srequirements and a quite general engineering background arealso needed. The t w o basic constituents of this latterrequirement are the FUNCTIONAL (measurement theoretical)and the IMPLEMENTATIONAL (measurement technological)EXPERTISE [ l I. The background for the functional expertiselies in measurement theory, which exposes the generalproperties of the measurement process. This kind of expertisecovers the specification of the measurement environment,information processing, and the evaluation of results. Theimplementational expertise relies on metrology and the measurement technology valid for the specific domain of application.The key issue of intelligent measuring system design is theformulation and efficient implementation of the expertiserequired. The complexity of this design procedure dependsmainly on the measurement problem at hand. In the field ofbiomedicine, this complexity is considerably high, and asksfor rather careful and systematic design approaches. Thesesystem design methods serve:Efficient implementation of conventional data processingalgorithmsEfficient implementation of knowledge-based data processing algorithmsThe efficient, event-driven real-time operating environment, andThe realization of problem-oriented user interface.The conventional data processing algorithms (i.e., estimations, decision schemes, etc.) can relatively easily be implemented using well-developed methods. The knowledgebased data processing algorithms are based on non-formalheuristic knowledge originating mainly in professional intuition and experience, but nevertheless very useful in solution18IEEE ENGINEERING IN MEDICINE AND BIOLOGY MAGAZINEsearching or for solutions w i t h excessive demand for operational time and resources.Regarding the implementation of heuristic knowledge, thefollowing three problems are t o be considered:Representation of knowledgeManipulation of the knowledge baseIntegration of the knowledge base with the numericaldata base and the algorithms within the unified real-timecontrol structure of the measuring system 121.The first t w o problems traditionally belong t o the researchfield of artificial intelligence [31, while the third one is anemerging chapter of measuring system design. The implementation and manipulation of the knowledge base, ingeneral, is a task w i t h significant time and resource requirements. Therefore, in real-time measuring systems its usage islimited by the built-in processing capability of the measuringdevices.In the following t w o sections, possible alternatives arepresented; first for t h e implementation of conventional dataprocessing and later for the knowledge-based data processing in measuring systems operating in a real-time environment. The topic of the problem-oriented user interface isoutlined in the subsequent section. The paper ends w i t h ashort presentation of an intelligent EEG recorder developmentb y the authors.FIXED VERSUS RUN-TIME PROGRAMMABLESOFTWARE ARCHITECTURESOne of the first experiences of the authors in the field ofmedical instrumentation, nearly ten years ago, was thedevelopment of a family of somewhat intelligent medicalinstruments for electrophysiological data recording and analysis. This family of instruments can be characterized by multichannel data acquisition, feature extraction, parameter estimation, and decision making capabilities, which areconnected t o processing real-time events and controlledthrough a problem oriented operator interface. The implementation of these functions requires considerable effort. H o w ever, similarities in data acquisition and signal processing, thenature of concurrencies, and real-time operation promiseanalogies utilizable in the design procedure -even of somew h a t different instruments. This analogy is also valid foroperator interface, where convenience includes the verysame "front panel philosophy" t o be applied for instrumentsof the same field. These encouraging facts have initiatedsteps towards standardization in several respects, such asdata acquisition, signal processing, real-time structures, andspecification methodology. By extracting the common elements, a quite general structuring of the software system ispossible, which results in a framework useful as a startingpoint for further development of instruments of similar types.In our experience, a three-level software module structure[41 can be used. The function-independent realization of thereal-time control structure provides an instrument "frame"on which real-time measuring instruments of various functions can be built up. For the sake of wide range applicability,the following requirements were raised against the realization:In the real-time structure, the elements determining thereal-time characteristics of the instrument should beseparated (e.g., priority dependent scheduling algorithms). These elements should be transformed into aform in which real-time requirements can be easilyexpressed.The real-time structure should be made modular. ThisJUNE 1 9 8 80739-5175/88/0600-0018 1.000 1988 IEEE
provides "tailorability"; in realization of a given instrument certain elements can be omitted or new elementscan be "pasted." In the course of designing moduleinterfaces, an effort should be made t o maximize information hiding [5].The module structure should be transformed into a threelevel structure:-modules for realization of real-time control structuresand its tables-modules for realizing measuring function and userinterface-general library modules.Of course, there are technological aspects of the realizationof module structure. As a minimal requirement, the languageapplied should incorporate tools for modular programming. Inthis case, the function related t o the real-time operation canbe accomplished by the explicit calling of a real-time operating system or a run-time operation system. Using a high levelreal-time language, the realization can be simplified becausethe elements of the access graph (process, resource, protected resource, synchronization, access rights) correspondt o the elements of the language (process type, module,interface module, procedure declaration/calling) [61. Thestructure modularized according t o foregoing requirements isshown in Fig. 1 (the figure does not contain all the legalaccesses). The function dependent modules are shaded in thefigure. On the base of naming and access rights, the elementsof the access graph can be identified.The main features of the module structure are:The uppermost level contains only the "frames" of theCOMMAND DECODER and M I . . . M m processes (mea-suring chain drivers). Having started, they immediatelyenter the second level, where the function dependentprocedures (PARSER, and M 1 1 . . . M m k ) are realized.(Of course, inside the level additional decompositionscan be performed.)The server processes can be utilized via the MEASurement CONTROL interface module. In order t o provideuniversal applicability, the MEASurement CONTROLmodule is table driven; the CONTROL TABLE containsparameters defining the specification of real-time operation (e.g., priority of measuring processes, type ofresources, restrictions of its utilization, etc.).The server processes handle special hardware units, sotheir algorithms depend on the measuring functions t o beimplemented.The lower level contains standardized library modulesthat supply implementing instrument dependent algorithms.Using the module structure presented here, the implementation of a real-time signal processing instrument with interactive user interface is simplified into sequential programming.A simplified version of the above discussed softwarearchitecture was used first in the course of the developmentof an EMG analyzer and later in that of an EEG signal analyzer.Experiences of these instrument developments have verifiedthe applicability of the software architecture presented. Themodularized system is easy t o manage, both in the moduleimplementation phase and in the system integration phase.One of the most advantageous feature is that the various userinterfaces and measuring data processing functions can beimplemented without any modification of the instrumentpn*lANSWERUTILITYUTILITY. .yHkk-1FROCESSINGARlTHMETICLIBRARYLIBRARYFigure 1. Module structure of a real-time signal processing medicalinstrument. Circles indicate process; squares indicate software modules.JUNE 1988IEEE ENGINEERING IN MEDICINE A N 0 BIOLOGY MAGAZINE19
"frame". Utilizing the frame of the EMG analyzer and thelibrary modules, the time needed for developing the EEGanalyzer shortened t o a quarter of the time needed for theoriginal EMG analyzer.Fixed software architectures, however, have several shortcomings when the flexible programmability of the measuringdevice is also required. In our experience, the development ofa general purpose signal processing system showed thatconventional command languages support neither the introduction of additional procedures and data structures nor themodification of their internal real-time behavior. A thoroughinvestigation of these shortcomings shows that the solutionof the following problems is required:Balance problem: Rather contradictory demands are t obe satisfied by a signal processing programming environment in the different phases of system development [71.The possible solution of the balance problem is obviouslya compromise among different requirements. However,without supporting this by appropriate conceptual andimplementational tools, the result will be time consumingand occasional.User interface problem: Programmable signal processingsystems require (in a sense) multi-tasking and a real-timeoperating environment, which support event-driven experiment control and interactivity w i t h the user. Theproblem is that, on the one hand, it would be desirable t oprovide high level user interfaces, while on the otherhand, high level tools may limit the appropriate application of the system facilities, which is not tolerable by theuser. However, if the user interface is solved by providinga lower level programming language, possibly havingreal-time facilities, the user will have a programming taskof higher complexity, which may easily reach the limits ofhis o w n programming ability.System interface problem: The typical (documented)interfaces of the traditional signal processing development system are shown in Fig. 2. Difficulties arise if anexisting signal processing system has t o be interfacedw i t h other programming languages or programs (e.g.,expert systems).Signal representation problem: Signal processing involves- besides numerical processing -some symbolicprocessing too (e.g., physical units transformation, derivation accounting), b u t traditional tools facilitate mostlythe numerical side of signal processing.As an attempt t o give a solution t o the above problems, w edeveloped an experimental programming environment forsignal processing (PESP), which gives a multi-level approacht o the design and implementation of various data acquisitionand signal processing programs and measuring devices. Theconceptual base of PESP is a description language for signalprocessing together w i t h an experiment control mechanismUSER USER1GENERAL PURPOSEPROGRAMMINGLANGUAGE(S)tIICOMMAND LANGUAGEFigure 2. Typical interfaces of traditional signal processing development systems.IEEE ENGINEERING IN MEDICINE AND BIOLOGY MAGAZINEUSERI1GENERALPURPOSE\LANGUAGEiIUSERIrnV MA NOLANGUAGEIRUN- TlMESYSTEM BUILDERSUPPORTFigure 3. Components of an experimental Programming Environmentfor Signal Processing (PESP).[81.The implementational components of PESP are shown inFig. 3.The run-time support level constitutes background for theexecution of the defined signal processing activity in a realtime environment.The system builder provides symbolic interface for theprovisions of the system. Its task is threefold:The system builder provides tools for building a networkfrom the primitives of the languages. Using this facilityyou can create signal processing instances from processing element types and connect them together by meansof signals.The system builder realizes multi-level abstraction; asubnetwork can be "boxed-up" and after that this itemcan be used as a higher level language "primitive" (anew processing element type).The system builder facilitates the modificationlexpansionof the language primitives. A user written signal processing function can be "merged" w i t h the existing library,after that, it appears as a n e w language primitive.Based on the system builder, different types of commandlanguages (shells, etc.) can be constructed. A very advantageous feature of a well-defined symbolic interface is that itssyntax can easily be converted t o another one (e.g., graphicrepresentation, dedicated keyboard).A generalpurpose programming language can be integratedinto this signal processing frame. A signal processing program written in that language can communicate w i t h theimplementational components of signal processing on different levels. It can directly use the element of the run-timesupport level (by means of function calls). It should bepointed out that in this organization even a sequentialprogramming language is suitable for realizing parallel signalprocessing chains. If the programming language used communicates w i t h the implementational components throughthe symbolic interface, the program has t o create thesymbolic description of the required signal processing architecture and pass it t o the system builder, which afterinterpretation, builds up the architecture.The operation of a signal processing program is based onaccepting, producing, and processing signals according t othe signal f l o w graph, which is a real-time and, in case ofparallel branches, parallel processing task. To insure appropriate run-time behavior, signal processing is executed on thebasis of an intermediate code. After defining the structure ofthe system, all the checkings and transformations of thenumerical and symbolical properties of the signals can becarried out in advance, before starting the system. Computa-}A,SIGNAL PROCESSING LIBRARY20USERJUNE 1988
tional power can thus be concentrated on pure data processing manipulations, which is not typical in conventionalcommand languages for signal processing. The run-timesupport gets the description of the signal processing systemin the form of an intermediate code from the system builder,and carries out all the real-time processing. The run-timesupport consists of three parts.The execufive reads the intermediate code, does thescheduling, tests the input signals if they are ready forprocessing or not, handles the control signals, and carries outthe experimental control, the testing, and the debuggingoperations.The extendable signal processing library contains all thebodies of the processes. Each process is build up from threeroutines: a data processing routine, a routine for testing andtransforming signal description tables, and a routine fortesting and transforming symbolic properties. (These last t w oparts, in fact, could be one routine, but the implementation ofthe numerical and symbolical computation is supported bydifferent tools. Here they are written in different languages.)The ufilifies consist of four main libraries: operating systeminterface, real-time kernel, signal processing utilities, andsymbolic package.The experimental version of the PESP was implemented onan IBM PC/AT computer using C and LISP languages.Signal processing systems developed using the programming environment described here can have high-level, symbolical user interfaces well suited t o the requirements of theapplication area and the operator, both in research androutine measurement situations.the active set of rules can be controlled (this is the way t oformulate meta-rules). The rule compiler determines the staticdependency among attributes, relations, and rules. Using thisinformation in the code generation phase, the number of rulematchings can be minimized and the propagation of the valueretraction can be controlled. Figure 4 shows the dependencyof the following rule set.RULE rl AND relation containing attrlbute al relation containing attrlbute a? , tell;re12 relation containing attribute al ;re13 relation containing attribute a? ;rely relation containing attribute a 3;re15CONCLUSION (setting attribute ay setting attribute aS RULE r2 ORCONCLUSION setting attribute a5 Arrows show the propagation of attribute value setting/retracting. A piece of code is generated:for each relation t o determine the truth value of therelationfor each rule t o propagate attribute value settingfor each rule t o propagate attribute value retraction.The appropriate invocation of the individual code segmentsis controlled by a small run-time system, which realizes theforward chaining control paradigm.Our rule compiler can generate C language or LISP code.The run-time system is written in C.INSTRUMENTS WITH REAL-TIME KNOWLEDGEBASED DATA PROCESSINGThese instruments can be considered as straight-forwardextensions of instruments dedicated t o "conventional" realtime analytical data processing. In this case, the analyticaldata processing chain is followed by a fact generator and a(typically forward chaining) inference engine.As an early experience, w e designed an intelligent EEGerinstrument assistant [ I 31, which involves and uses somemeasurement technological knowledge. The results of theexperience were:It is difficult t o build a rule base using two-valued factsbecause of the l o w level expressing power.Since these two-valued facts are produced by the factgenerator, the modification of the knowledge base (rulebase) usually also induces the modification of the factgenerator.A s a consequence of the varying instrument environment, the inference engine should have fact (value)retraction capability.For the sake of focusing the searching, meta-rules shouldbe used.Keeping the run-time on a considerably l o w level, rulecompilation should not be put aside.The updated version of the instrument mentioned abovehas the following rule structure.RULE i d AND I O R relation relation , ,.CONCLUSION cattribute setting cattribute setting .OCTION-SET actions to be done in case OFACTION-RET actions to he done in case OFrule iring retracting,where (relation) is a relational expression on attribute values.There are t w o special actions (INCLUDE, EXCLUDE) by which?wFigure 4. The dependency graph of the sample rule set.PROBLEM-ORIENTED USER INTERFACEThe main
short presentation of an intelligent EEG recorder development by the authors. FIXED VERSUS RUN-TIME PROGRAMMABLE SOFTWARE ARCHITECTURES One of the first experiences of the authors in the field of medical instrumentation, nearly ten years ago, was th
