JP2010017563A - Diagnostic network system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a diagnostic network system by which monitoring (checking) and repairing of medical modality etc. can be performed in high reliability at low cost to provide problem solving measures to a user or service engineer upon the occurrence of troubles. <P>SOLUTION: The diagnostic network system 10 includes a plurality of distribution type checking units 12, a master distribution type checking unit 34, a network 13 enabling transmission of information by connecting communication media, and a system monitoring unit 16 to communicate with the plurality of distribution type checking units 12. The system monitoring unit 16 includes an edition information database edited based on information relating to motion information, a means to analyze the collected information to constantly determine whether or not checking and repairing is required for a plurality of devices, and a diagnostic unit including a means to indicate tools and a processing procedure of checking and repairing required for performing trouble shooting on devices requiring checking and repairing corresponding to the communication with a user interface 18. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention is a modality in which a number of different module devices are connected to each other and have specific functions (for example, blood vessel X-ray imaging system, MRI (magnetic resonance imaging) system, X-ray CT scanner, nuclear medicine diagnostic apparatus, biomagnetic field measurement). The present invention relates to diagnostic (testing, inspection, management) methods including monitoring, maintenance (inspection), and repair of target systems such as devices.

  Conventionally, as an example of this type of modular system, there are various medical modalities. For example, in the case of a blood vessel X-ray imaging system as a medical modality, a typical configuration includes a patient table, an operator console, a control panel, and a high voltage transformer as modular devices, and these modular devices are electrically connected. Has been. As a result, blood vessel imaging of the patient can be performed as a whole.

  It is costly to inspect and repair each component of these modalities. If it is designed modularly, the system can be constructed to match the customer's individual requirements. On the other hand, repair and maintenance become complicated. In other words, since the repair and maintenance must be performed for each module, the overall cost for repair and maintenance is high.

  To perform repairs and maintenance, the field service engineer must have an on-site technical manual and repair procedures to investigate any troubles that may occur. However, again, the system is modular, which creates a problem. Vascular x-ray imaging systems are typical. Since a variety of modules are used in this system, a technical manual and a procedure manual for each module become a hand of the field service engineer. This was a considerable amount of paper, very inconvenient and poorly mobile.

  When diagnosing a system trouble (problem) of a modality, there may be a problem solving method based on the diagnosis result, but it may be missed, and the problem solving always includes a trial and error element. In other words, it often took a lot of time and effort to reach an appropriate problem solution. For example, in order to diagnose a trouble, a field service engineer needs to execute a procedure for solving a problem or frequently refer to a technical manual to execute such a procedure. In many cases, even if the first processing procedure is executed, the trouble is not solved. In this case, it is necessary to execute an additional processing procedure. This is extremely time consuming and diagnostic costly. In addition, as a result of executing the processing procedure, it may be necessary to replace parts. In addition, even if the part is replaced, the system may still not work as expected.

  In order to determine the cause of the trouble, it may be necessary to execute a procedure for solving two or more times. Once the cause of the trouble has been determined, more processing steps need to be performed to determine how to repair or replace such malfunctioning component. Even an experienced field service engineer can identify a problem more easily and know the steps to solve it, but even such an experienced field service engineer can There are some troubles that rarely occur so clearly that they are misdiagnosed.

  Another cost-increasing factor is the effort to ensure optimum performance after maintenance and inspection. This optimal performance is often empirically owned by the user. That is, each doctor who uses an image generated by the system has unique performance parameters, which are optimum parameters for each doctor. Therefore, what is important is that the state of optimal performance can be easily reconstructed after diagnosis (testing, inspection, management) and the system is returned to a setting that can exhibit the performance characteristics preferred by individual users. Conventionally, it takes a lot of time and labor to reproduce the optimum performance.

  Conventionally, when the system performance status of the modality is monitored, it has been modularized, which requires a lot of trouble. In particular, in the case of a vascular imaging system, the labor is often complicated. This is because a large number of system components are typically placed in various rooms and may receive power from separate power sources. In general, electrical safety, grounding and distance issues arise.

  The present invention has been made in view of the various problems related to the conventional monitoring, maintenance, and inspection described above in a modular system, and its main purpose is to significantly reduce the cost of monitoring, maintenance, and inspection. To provide a diagnostic network system for a modular system capable of presenting a reliable problem solution when a trouble occurs.

  Another object of the present invention is to contribute to reducing the cost of diagnosis by reducing the hand-held items of field service engineers who maintain and inspect the modular system, improving convenience and mobility. is there.

  Still another object of the present invention is to eliminate or reduce trial and error elements when diagnosing troubles (problems) in a modular system, and to efficiently present a problem solution to contribute to cost reduction of diagnosis. To do.

  Yet another object of the present invention is to enable even an experienced field service engineer to present an accurate solution to a trouble of a modular system that occurs in a difficult manner. is there.

  Yet another object of the present invention is that the modular system can be easily returned to its previous optimal performance state after maintenance, inspection and troubleshooting, which also reduces the total time and effort required for maintenance. It is to be able to plan.

  Yet another object of the present invention is to easily and reliably monitor the performance state of a modular system online and to improve the reliability of system management.

  The diagnostic network system according to the present invention is a diagnostic network system that communicates with a plurality of devices, and communicates with each of the related devices individually among the plurality of devices to constantly obtain information on the operation state of the devices, A plurality of distributed test units to be collected; a master distributed test unit; and a network in which the master distributed test unit and the plurality of distributed test units are connected to each other via a communication medium to enable transmission of information; A system monitor unit that communicates with the plurality of distributed test units via the master distributed test unit, and communicates with the system monitor unit and communicates with each of the plurality of distributed test units to the user A user interface for providing the system monitor The storage unit stores a control unit that collects information about the operation state from the plurality of distributed test units, and edit information that is edited based on the information about the operation information collected from the plurality of distributed test units. A database for analyzing the collected information, a means for constantly determining whether or not the plurality of devices require inspection and repair, and inspection of the plurality of devices according to communication with the user interface And a diagnostic unit having a tool necessary for troubleshooting a device requiring repair and means for indicating a procedure of inspection and repair.

  According to the diagnostic network system of the present invention, the monitoring, maintenance and inspection costs of a plurality of devices (modules) mounted on a modularized system such as a medical modality can be reduced, and a reliable problem solution can be provided when a trouble occurs. It can be provided to users and service engineers. Furthermore, it is possible to provide a diagnostic network system that can be monitored (maintenance / inspection) and repaired more easily, with low cost and high reliability. Further, it is possible to provide a distributed test unit that can be suitably used for this diagnostic network system.

The figure which shows an example of the diagnostic network system of this invention. The figure of an example of the diagnostic network system of the present invention when connected to a blood vessel imaging system. FIG. 2 is a conceptual diagram of an on-site portion (represented by the lower circle) and off-site support (represented by the upper circle) provided by the TAC according to the diagnostic network system of the present invention. The figure of the diagnostic network system of the star arrangement composition concerning the present invention. Sectional perspective view of a generalized DTU module. The functional block diagram of the microprocessor module common to each DTU module. The functional block diagram of the power module common to each DTU module. Schematic diagram of a sample control module common to kV, mA DTU, PMT DTU, dosimeter DTU, and master DTU. Master pin assignment table for multi-pin connectors used in DTUs. FIG. 4 is a diagram of a DTU microprocessor memory map consisting of RAM and EPROM memory. FIG. 5 is a diagram of communication data flow between a network and a sample control module when controlled by a DTU microprocessor. Block diagram of dosimeter DTU. The block diagram of the operator console DTU connected to the operator console. The conceptual diagram of the function performed by a system monitor. The flowchart of a resolution processing procedure. The figure which shows the problem isolation algorithm used for the resolution processing procedure. The figure which shows the problem isolation algorithm used for the resolution processing procedure. The flowchart which shows a focus test processing procedure. The flowchart which shows a focus test processing procedure. The flowchart which shows a half value test process sequence. The flowchart which shows a quick pipe | tube calibration check process procedure. The flowchart which shows a quick pipe | tube calibration check process procedure. The flowchart which shows a check MAX ERR process sequence. The flowchart which shows an indirect imaging | photography dose data processing procedure. The flowchart which shows an indirect imaging | photography dose data processing procedure. The flowchart which shows an indirect imaging | photography dose data processing procedure. FIG. 3 is a conceptual diagram showing a session hierarchy, a data link hierarchy, and a physical media connection related to communication between two DTUs according to the present invention. The figure which shows the component of the data link hierarchy packet of FIG. The figure which shows the data link frame structure of the DTU network protocol of FIG. The figure which shows the structure of the session hierarchy packet of FIG. The figure showing the "sliding technique" which raises the reliability of data transmission. The figure showing the "sliding technique" which raises the reliability of data transmission. The figure showing the pseudo code for starting with respect to DTU. The figure which shows the general | schematic starting sequence with respect to general DTU. FIG. 3 represents an annotation session of a DTU network according to the present invention. The figure which shows the example of the screen from a smart book (SmartBook), and shows the graphical user interface software provided to a field engineer when logging to this system. The figure which shows the example of the screen from a smart book (SmartBook), and shows the graphical user interface software provided to a field engineer when logging to this system. The figure which shows the example of the screen from a smart book (SmartBook), and shows the graphical user interface software provided to a field engineer when logging to this system. The figure which shows the example of the screen from a smart book (SmartBook), and shows the graphical user interface software provided to a field engineer when logging to this system. The figure which shows the example of the screen from a smart book (SmartBook), and shows the graphical user interface software provided to a field engineer when logging to this system. The flowchart figure explaining the menu option which can be used by the field service engineer in the diagnostic network system of this invention. FIG. 42 is an operation sequence diagram illustrating the “troubleshooting” process of FIG. 41. FIG. 42 is a flowchart for the “utility” option of the diagnostic software according to the present invention in FIG. 41. FIG. 42 is a flowchart for the “utility” option of the diagnostic software according to the present invention in FIG. 41. FIG. 42 is a flowchart for the “utility” option of the diagnostic software according to the present invention in FIG. 41. The explanatory view of the diagnostic network system concerning one example of development of the present invention. Explanatory drawing of the diagnostic network system which concerns on another one development example of this invention.

  An embodiment of a diagnostic network system according to the present invention will be described with reference to the accompanying drawings.

  The diagnostic network system 10 includes three main components as shown in FIGS. 1) a hardware network 13 consisting of distributed test units (DTUs) 12 and predetermined on various modules that make up a vascular system 14 (see FIG. 2). Components that can be attached to test points, 2) a system monitor box 16 that receives and handles data from the DTU 12, and 3) a field service notebook 18 (conventional laptop computer) comprising: A component that serves as an interface to the service engineer's system monitor box 16 and allows the user to access the diagnostic network system 10 of the present invention. A Technical Assistance Center (TAC) 19 conceptually shown in FIG. 3 is another component of the present invention.

[System Architecture]
One of the preferred embodiments according to the diagnostic network system 10 of the present invention is the simplest configuration in which DTUs 12 are connected in series as shown in FIGS. With this configuration, operation data is continuously collected at designated test positions of each device (module device) of the blood vessel imaging system 14 and the information is sent back to the system monitor box 16. As shown in FIG. 2, the vascular imaging system 14 used for radiography includes a collection of modular devices such as a high voltage transformer 78, a patient bed 17, a C-arm 15, a control panel 32, and a console 30. Consists of. The DTU network 13 and the system monitor box 16 are disposed on-site and connected to a module device of the blood vessel imaging system 14. Each of the DTUs 12 is connected to each other by an optical fiber network 24. In accordance with the preferred embodiment, TOTX 173 / TORX 173 and TOCP 172 optical fiber cables available from "Toshiba America Electronic Components Co., Ltd." are used as the optical fiber network 24. The maximum length of the optical fiber network 24 between each DTU 12 is 10 meters. Field service notebook 18 is brought to the site by a field service engineer and connected to system monitor 16 using Ethernet connection 20. The field service notebook 18 is provided with a graphical user interface (GUI) 22 so that the field service engineer can communicate directly with the DTU network 13.

  As conceptually shown in FIG. 3, TAC 19 additionally provides technical support, functional statistics, expert knowledge, and external data off-site via modem link 26 or other appropriate data line. It is obtained by. This off-site support is provided to the on-site field service engineer, which helps to effectively function the diagnostic network system according to the present invention.

  As can be seen in FIGS. 1 and 2, system data sample capability is provided by a DTU 12 located at a predetermined test location of the vascular imaging system 14. For example, the DTU 12 is disposed on components such as the dosimeter 28, console 30, control cabinet 32, and high voltage transformer 78 of the vascular imaging system 14. Each of these component test locations is provided with a different DTU, which is provided to monitor specific parameters of its associated component. For example, the dosimeter 28 includes a dosimeter DTU 38, and X-ray dose information is collected. The DTU network 13 is connected to a master DTU 34, which is connected to the system monitor box 16 by a multi-pin cable 36 such as a conventional 25-pin cable.

  The plurality of DTUs 12 are connected in series to form a closed loop of a loop starting and ending at the master DTU 34 as shown in FIG. A star-shaped connection as shown in FIG. 4 may be made, which can overcome some of the disadvantages envisaged for a series connection.

  In the case of the hardware configuration of FIG. 2, the master DTU 34 has a parallel port 40 </ b> A, and the master DTU 34 is connected to the LPT port 40 of the system monitor box 16 through this. In this LPT port 40, 4 bits are used for data input and the remaining 4 bits are used for output data. The master DTU 34 has an optical receiver / transmitter 54 (see FIG. 6), and communication with the optical fiber network 24 is possible. The master DTU 34 receives a digital signal from the system monitor box 16 and converts it into an optical signal for the DTU network 13. When the master DTU 34 receives the data returned from the individual DTUs 12, the master DTU 34 converts the signal from the optical signal form into the digital signal form, and passes the signal to the system monitor box 16 for analysis.

  During the operation of the master DTU 34, the master DTU 34 sends data to the first DTU 12 in the closed loop, the first DTU 12 retransmits the data to the second DTU 12, and this is performed in sequence. DTU 12 sends such data back to master DTU 34 to complete the loop. When the DTU 12 is a serial network, the cost advantage is the best because only one optical fiber network 24 is required to connect all the DTUs 12 to form a loop.

  Disadvantages of this serial connection method are: a) when one DTU is powered down, the entire network loop becomes inoperable, and b) optical pulses are distorted during transmission. The distortion lowers the performance of high-speed optical communication and becomes a low-speed mode. These disadvantages will be explained using a combination of star loop type network configurations as shown in FIG.

  An example of a star loop network is shown in FIG. In this embodiment, four or more optical input / output channels are used so that all the DTUs 12 essential to the diagnostic network system can be accessed by individual links of the fiber optic cable network 24. Second, DTU 12 can also be connected in a loop. Since the main DTU 12 can be directly accessed, a situation in which the entire network becomes inoperable even if one DTU 12 fails is prevented. One disadvantage of the star configuration is that an additional optical cable is required to connect separately. However, each loop can have a dedicated master DTU circuit assigned to that loop, and the master DTU circuit can be similar to the master DTU 34 described in connection with the closed loop embodiment of FIG. Alternatively, a multiple arrangement configuration in which a set of master DTU circuits is shared by several loops can be adopted.

[Distributed test unit]
The DTU 12 will now be described in more detail with reference to FIGS. The DTU 12 is a portable data acquisition unit, and is configured to be connected to a predetermined test position on a component (module device) of the blood vessel imaging system 14, and in the normal operation of the imaging system or in the imaging system. This connection is possible without affecting the image quality produced. The DTU 12 functions as a “sensory organ” of the diagnostic network system of the present invention, collects data, and sends it to the system monitor box 16.

  As shown in FIG. 5, three basic modules are provided in the form of a shoulder wheel to form one DTU 12. 1) a microprocessor module (MM) 46, 2) a power module 48 (PM), and 3) a sample control module (SCM) 50. These modules are preferably connected by a stackable multi-pin connector 52 as shown in FIG. The DTU 12 can be tailored to a specific test location by selecting the appropriate SCM module 50 and stacking it together with the microprocessor module 46 and the power module 48. Microprocessor module 46 and power module 48 are preferably invariant for each DTU 12. The DTU 12 is equipped with an LED 104 (shown in FIG. 1), which provides status information and displays whether the DTU 12 is operating after activation.

  The microprocessor module 46 has a Toshiba 68HC11AO microprocessor 44 capable of turning off the battery power, together with a memory in the network and an optical input / output capability for connection. The DTU 12 has analog or digital inputs and outputs for connection, at least one pair being optical to one component of the vascular imaging system 14, such as a dosimeter.

  Each of the test locations where the DTU 12 of the vascular imaging system 14 is placed serves a different function. Accordingly, various types of SCM 50 are used. However, the power module 48 and the microprocessor module 46 are common to each DTU 12. Although all DTUs 12 are generally similar, input conditions and operating levels (voltage and value) may vary.

  The predetermined test location where the DTU 12 is attached is the location considered most important in obtaining the highest possible image quality. Each DTU 12 performs several functions. This function includes 1) waiting while monitoring commands from the system monitor box 16 that have been seen through the fiber optic network 24, 2) monitoring input to a predetermined test location, and / or 3) holding a predetermined value. Changing the test position to include. For example, the DTU 12 can operate as a positive feedback control system, which feeds back as an input until the output reaches a certain predetermined value. Thus, for example, if the user wishes to increase the radiation of the dosimeter 28 to a certain value, the dosimeter DTU 38 increases the radiation in increments until the specified output value is reached.

  The microprocessor module 46 is integrated into a power module 48 and a test location specific SCM 50. A signal necessary for controlling the SCM 50 is supplied from the microprocessor 44 through the multi-pin connector 52. The preferred architecture of the microprocessor module 46 shown in FIG. 6 includes an optical receiver and transmitter 54, a microprocessor 44 such as Toshiba model 68HC11A1 or equivalent, EPROM 58, a bank of RAM 2000 memory 56A, RAM 6000. A bank of memory 56, a bank of RAM 8000 memory 56C, and a field programmable gate array (FPGA) 64 are included. Microprocessor 44 transmits information via a data / address bus connected to multi-pin connector 52. FIG. 9 shows an example of signal assignment of the multi-pin connector for each of all the DTUs 12.

  The optical receiver and transmitter 54 converts the light pulses received from the fiber optic network 24 into electrical signals that are recognized by the communication port of the microprocessor 44. As shown in FIG. 6, the microprocessor 44 operating in the extended multiplexing mode accesses the external RAMs 56A, 56B, 56C and the EPROM 58, and the I / O. A typical example of the memory map of the microprocessor 44 is shown in FIG.

  Each DTU 12 transmits and receives data using two microprocessors 68HC11A0 connected in series in the microprocessor 44. The serial communication interface (SCI or RS232) 60 and the serial peripheral interface (SPI) 62 are shown in FIG. 11 as shown. The crossbar switch 64 is used to connect the optical link and electrical link to the test position, ie RS232 60 port or SPI 62 port, as commanded in the format of information switched between the system monitor and test position. The crossbar switch 64A is implemented as a part of the FPGA as shown in FIG. Code / decode logic 65 converts a signal in MOS I / SCK format to Rx / Tx format or vice versa.

  Instead of having all traffic on the network go through the microprocessor 44, the SPI 62 receives information from the optical receiver 54 and retransmits the signal to the optical transmitter 54. The retransmitted signal is modulated again to compensate for optical pulse width distortion. (See PAL retransmission switch 53.) Thus, many DTUs 12 can be connected in series without accumulating pulse width distortion.

  In the case of a general DTU 12, eight analog signals (0 to 2.5 V range) can be sampled. The microprocessor 44 includes an A / D converter 66 therein. Analog data sent from the test location passes through the multi-pin connector 52 and reaches the microprocessor 44 which is directly coupled to the multi-pin connector.

  The analog data is then converted into a digital format within the microprocessor 44 by passing through the A / D converter 66. The SCM 50 uses an external data / address bus together with chip select logic, and can interface with another DTU from the DTU 12 (address range 0800-OFFF, FIG. 7). The first four (A0- + 5V, A1-BATT.1, A2-BATT.2, A3- + 12V) input channels are used to monitor the power module 48 (see FIG. 5). Monitor the + 5V supply voltage on the first channel. Monitor the two batteries used in the DTU 12 on the second and third channels. The voltage of the internal DC / DC converter is monitored by the fourth channel. The last four analog channels can be used to sample data from any one of the test locations.

  Each DTU 12 preferably includes its own power module 48 having a battery 68 and a 24 VDC input 70 (FIG. 5) to hold the necessary data for up to one hour. The battery 68 is charged from an internal DC / DC converter 72. During “power on” of a DTU 12, the 24 V power applied to the input 70 can be generated from either an external power source or a DC power line inside the vascular imaging system 14. The DC / DC converter 72 converts a 24V input voltage into a 12V output voltage with a maximum current of 500 mA. If this machine cannot access the 24V power supply, an external wall plug transformer with an output of 24V DC is used. The converter has a 500V 3000V input / output isolation rating. An example of a system diagram of the power module 48 (common to each DTU) is shown in FIG.

  This power module 48 is connected to a DC / DC converter 72 through a relay switch 74. When high noise immunity is required, the power module 48 is physically disconnected from the DC / DC converter 72 and powered from the internal battery 68 for the short time required for data collection during the X-ray exposure period. can do.

  Each of the DTUs 12 has special characteristics of the DTUs 12 derived from the SCM 50 they have. The system diagram of the SCM 50 is common to kV, mADTU 76, master DTU, dosimeter DTU 38, and PMT DTU 80, as shown in FIG.

  As shown by the examples of FIGS. 12 and 13, since an appropriate SCM 50 has been selected, another specific DTU, such as a dosimeter DTU 38 or console DTU 88, depending on where the typical DTU 12 is located in the vascular imaging system 14. Can function as a mold. (See FIG. 2.) Data from the test location, such as from the dosimeter 28, is viewed at the DTU 12 via the test location connector 51 on the SCM 50. Switch 200 is controlled by commands on lines B4 and B5 to switch between the reference voltage and the test position signal. The divider 59 provides the full scale and scaled level signal from the switch 200 to the instrumentation amplifier 202.

  Instrumentation amplifier 202 then drives lines AIN 6 and AIN 7 leading to multi-pin connector 52. Thus, data is sent to the microprocessor module 46 through pins AIN6 and AIN7 of the multi-pin connector 52. The SCM 50 includes an RS232 connector 55 for communicating with a monitor or field service engineer's laptop computer. A MAX 232 RS232 chip 57 is provided, which converts from this data signal RS232 format (and to this format) to the ± 5V format used by the SCM 50. The types of DTUs 12 and their respective SCMs 50 used in the diagnostic network system of the present invention are exemplified below.

[KV, mA DT]
The SCM 50 of the kV, mA DTU 76 can be connected to a TERMINAL-A PWB located on an HV generator tank 78 (high voltage transformer) or to a FEEDBACK PWB. (See FIG. 2.) The voltage and / or current at test location 51 is measured by kV, mA DTU 76. The SCM 50 functions as an interface between the test position and the DTU 12. A set of operational amplifiers convert the mA signal to a voltage level proportional to this current level. A + kV / −kV signal is distinguished by a similar circuit and becomes an absolute kV signal. This mA amplifier needs to operate within a signal range of 4 to 1500 mA (indirect shooting / shooting mode). Thus, to accommodate the various ranges, a degree of amplification programmed through the programmable register divider 59 of FIG. 8 is provided.

[Photomultiplier tube DTU]
A voltage applied to the PMT 80A is measured by a photomultiplier tube (PMT) DTU80. Using a simple op amp circuit, the PMT voltage can be converted to a level measured by the microprocessor module 46 (similar to kV, mA SCM).

[Dose meter DTU]
A dosimeter DTU 38 (shown in FIG. 12) is typically connected to the dosimeter 28 and measures the radiation incident on the imaging tube. The dosimeter DTU 38 controls the 35050A or equivalent dosimeter 28 using the RS232 link, sets the appropriate range and mode, requests data, and sends the data to the system monitor box 16 through the fiber optic network 24. To transmit. The SCM 50 (shown in FIG. 8) for the dosimeter DTU 38 is designed for a “Keithley” type dosimeter, but the design can be changed if another type of dosimeter is used. A device similar to MAXIM MAX 232 is used for this SCM 50, which converts the 0-5 V RS232 level from the microprocessor 44 into the 9 V level required for the dosimeter 28. The dosimeter 28 is powered only from the internal battery and cannot be turned on remotely. The operator must press the “POWER ON / OFF” button to activate it. However, the dosimeter turns itself off after the “unmanned operation” period of 1 to 255 minutes selected by the user has elapsed.

[Technique Selector / Console DTU]
The technique selector (TS / console) DTU 88 (shown in FIG. 2) is connected to the operator console 30 and asks the operator's console 33 to determine if the technique selector has been selected by the operator. In addition, the DTU monitors and reports all actions performed by the user. For example, the DTU monitors and records the selection of techniques such as kV, mA setting, focus selection, x-ray tube selection. The state or technique of kV, mA can be selected and confirmed remotely from the TS DTU 88 without operator intervention, enabling full automation of many procedures. As will be described later, the calibration state of the blood vessel imaging system 14 can be confirmed by comparing the measured value of the DTU 12 with the set value of the operator console 30.

  The TS / console DTU 88 also drives the operator console 30 automatic test function. Therefore, the blood vessel imaging system according to the present invention uses the measurement values of the test positions reported by the respective DTUs 12, and compares these measurement values with the setting values recorded on the operator console 30 by the technique selector DTU 88, thereby determining the accuracy. Can be secured.

[Master DTU]
This master DTU 34 is the first and last DTU in the loop as shown in FIG. Master DTU 34 is adapted to perform protocol storage and data buffering functions between system monitor 16 and fiber optic network 24. Although the SCM 50 of the master DTU 34 is schematically shown in FIG. 8, this SCM outputs necessary signals and links the master DTU 34 to the LPT port 40 of the system monitor box 16 via the parallel port 40A. For this communication, the “Standard Lap-LINK” or “Interlink” protocol is used. The SCM 50 between the master DTUs 34 uses a digital signal buffer 204 between the multi-pin connector 52 and the LPT port 40 of the system monitor 16.

  The input signal is sent from the LPT 40 of the system monitor box to the parallel port 40A of the master DTU 34 using eight data lines and one strobe line. The signals “SELECT”, “PAPER END”, “ACKNOWLEDGE”, “BUSY”, and “ERROR” are used as output signals from the master DTU 34 of the system monitor box 16. The master DTU 34 collects 4-bit (+1 strobe) nibbles using a protocol similar to RS232 and packs the nibbles into blocks that are acceptable by the network protocol. Thus, communication between the system monitor 16 and the optical fiber network 24 can be simplified using the standard LPT port 40.

  The blood vessel imaging system of the present invention can be configured without the master DTU 34. In that case, the master DTU 34 performs high-speed optical communication between the system monitor box 16 and the DTU network 13. Replace with the circuit inside.

[System Monitor Box]
This system monitor box 16 (shown in FIGS. 1, 2 and 14) controls all other DTUs 12 through the master DTU 34, inquires information from those DTUs 12, and sends back data sent back by those DTUs Process. The system monitor box 16 can communicate with any of all the DTUs 12 individually. When the system monitor box 16 sends a request / command to each DTU 12, in response, the DTU 12 collects each sample data from the device to which they are assigned. The system monitor box 16 can analyze the data provided by each DTU 12 to determine a change occurring in the blood vessel imaging system 14. The system monitor box 16 can also provide commands to one DTU 12 to reconfigure itself to another type of DTU 12.

  The system monitor box 16 is a computer as conceptually shown in FIG. 14, which is a parallel port interface (LTP) port 40 for connection to the master DTU 3 via a multi-pin cable connector 36, and It has an Ethernet connection 20 for connection to a field service notebook computer 18. This system monitor box 16 has as its hardware a CD-ROM storage device 94 or equivalent, multimedia capability, modem 96, Ethernet connector 20, sound board 98 with speakers, graphics capability, hardware key 100, And a barcode reader 102. The system monitor box 16 can also be booted from the CD-ROM 94. System monitor 16 is preferably run on Windows-based software from "Microsoft". The system monitor 16 may also run on next generation software platforms such as Windows '95 or UNIX.

  As shown in FIG. 14, the system monitor box 16 controls all the main system functions of the diagnostic system. All information and functions necessary for operating the diagnostic network system 10 according to the present invention are as shown in FIGS. 36, 37, 38, 39 and 40, except for a graphical user interface (GUI) 22 by software. Included in the system monitor box 16. The current and past performance information files of this system are stored in the on-site database 110. The system monitor box 16 is equipped with a remote access capability 111, which communicates with this site by this remote access capability and can be monitored by the TAC 19. CD-ROM 94 contains documentation (manuals and procedures), equipment specifications, and video support CDs necessary to perform on-site service activities.

  Also, a remote user can use the remote access function 111 to transfer files (for example, error logs and site history information) from the system monitor box 16, access the database of the system monitor box 16, and perform remote control such as diagnosis or control of the DTU 12. Execute the function, receive the software correction information, schedule the execution function of the DTU 12 (that is, the remote command to the system monitor box 16 such as “sample DTU # 2 every 10 seconds”), and schedule the operation of the system. Can stand. The system monitor box 16 also performs self-diagnosis and diagnostics on CD-ROM access, DTU 12 network, LPT port 40, serial port 108, and Ethernet connection 20.

  When a field service engineer connects a field service notebook (computer) 18 to the system monitor box 16 through an Ethernet connection 20, network data can be accessed. Diagnostic information is obtained through the system monitor box 16, and troubleshooting and holding of each DTU 12 can be performed. The system monitor box 16 can also assist field service engineers using diagnostic procedures. Both the field service engineer and the TAC 19 can remotely contact the system monitor box 16 via the modem 96 to access the DTU 12 network and check the operation of the system. The system monitor box 16 can also initiate contact with the TAC 19. The TAC 19 can also send e-mail or technical report information to the system monitor box 16 for reading by a field service engineer.

  After the system monitor box 16 analyzes the data sent from each DTU 12, the result can be automatically sent to the TAC 19 via the modem 96. If for some reason the TAC 19 line is busy, the system monitor box 16 spools the data it wishes to send for later transmission (processing to the queue). Further, the system monitor box 16 allows the user to make a data log or file transmission schedule from the system monitor box 16 to the TAC 19. For example, the error log and operation log of the system monitor box can be scheduled for transmission every 8 hours.

  The system monitor box 16 analyzes test position data such as dose, signal amplitude, resolution, and field uniformity sent from each DTU 12. During installation or calibration, field service engineers enter acceptable values for each of the parameters (test locations). For example, an acceptable dose value can be set between 0.08 and 0.09. Once these values are entered, they are stored in the system monitor box database 110. When such a situation is commanded, the system monitor box 16 reads the current value from the corresponding DTU, such as the dosimeter DTU 38, and then the read value is sent to an expert system provided in the system monitor box 16. hand over. The expert system 115 compares the read value with a set value and determines whether the read value is within an acceptable range. The determination of expert system 115 determines what procedures or actions should be taken to the user during repair and maintenance of vascular imaging system 14.

  Since this system monitor box 16 executes a number of diagnostic processing procedures, the guesswork associated with system repair can be reduced. As shown in the example of FIG. 15, the field service engineer is guided through the analysis process by the “Resolution Procedure”, and the resolution of the image is corrected. As a result, a video image like a thin aorta from the X-ray is displayed on the screen for observation by a doctor. The image quality may be degraded to little or no value for the physician. In such a case, image quality degradation is caused by the poorness of the image tube (which takes about 40,000 US $ to replace it), or the X-ray tube (which is quite cheap). It may be due to

  This resolution processing procedure involves a series of separation techniques to determine the true cause of the problem. This procedure displays instructions on the field service engineer's notebook computer. The field service engineer then inserts the phantom object in the x-ray imaging area. This phantom object is a lead screen and is provided with wires having a predetermined interval and a predetermined thickness. Using the algorithms written in the C and C ++ languages shown in FIGS. 16 and 17, the resolution processing procedure determines at which position the image resolution can be measured (normal mode, enlarged I mode, or enlarged II mode). . If the resolution can be measured in any of these three modes, the image tube is good. The resolution processing procedure then executes another processing procedure such as “Display Master Objective Lens”. If the master objective lens is good, then the “Check Focal Spot Size” procedure shown in FIGS. 18 and 19 is performed.

  Until now, field service engineers have tried to solve this resolution problem, and even if the filament of the X-ray tube was actually defective, the image tube was the cause and replaced it. Maybe. The system 10 of the present invention avoids such errors by anticipating all possible causes for a problem that has occurred and automatically eliminating / erasing inappropriate solutions.

  Other processing steps performed by the expert system include a half-value test (which determines the hardness of the X-ray beam, for example), a quick tube calibration check, Check Max Entrance Exposure Rate (Check Max Exposure Rate) and Fluoro Dose Data (Flouro Dose Data) procedures, etc. are shown in FIGS. 20, 21, 22, 23, 24, 25, and 26, respectively. It is shown.

  Those skilled in the art will readily recognize that these procedures are merely examples of the many processing procedures that can be stored in the system monitor box 16 and executed by the expert system 115. These procedures are performed on a software package marketed under the name “NexPert” produced by “Neuron Data Corp.” located in Palo Alto, California.

  The system monitor box 16 also has a safety function. Remote users, such as TAC 19 and users connected to system monitor box 16 via field service notebook 18, are attached to user login and parallel port 106 of field service notebook 18. It is proved through a user password associated with the hardware key 100. This certification information is held in the system monitor database 110. A hardware key can be temporarily provided and used for installation and testing of the diagnostic network system 10. During installation, when the field service engineer places a confirmation call to TAC 19, TAC 19 now makes the key site-specific.

  The expert system 115 also utilizes execution and history information stored in the system monitor box database 110. The system monitor box database 110 includes error logs, activity logs, problem solving logs, result logs (providing system evaluation test results), hardware key information, and system monitor module version information (each process and software version). (Including release version and revision information). This information is used collectively to support diagnosis by expert systems.

[Field Service Notebook]
The field service notebook 18 is provided in the diagnostic network system 10 according to the present invention. As shown in FIGS. 1, 2, and 14, when the field service engineer arrives at the site, the field service notebook 18 is connected to the system monitor box 16 through the Ethernet connection 20.

  The graphical user interface software tool 22 then allows the user to communicate with the system monitor box 16 and access all of the diagnostic and maintenance functions, including each DTU 12. Field Service Engineer Notebook 18 includes a microprocessor such as “Intel 386” or “486” or equivalent portable computer, graphics capabilities, “Windows”, and a Windows-based graphics user interface ( GUI). According to a preferred embodiment of the present invention, the “SmartBook” from Toshiba America Medical Systems, Inc., located in Tustin, California, can be used as the GUI.

[Technical Assistance Center]
The Technical Assistance Center 19 (TAC) is a central information source of the diagnostic network system 10 of the present invention. See FIG. Tools for TAC engineers can usually be obtained from the user interface, which allows the TAC engineer not only to upload and view images from the on-site system monitor box 16 but also to upload log files, The performance status of the system can be reviewed. In TAC19, not only a complete site history, but also an on-line expert system can be used as well. Technical experts available at TAC 19 can assist field service engineers with questions about diagnostic network systems that require rapidity.

  The TAC 19 hardware includes a plurality of conventional personal computers (PCs) with internal modems, a plurality of Ethernet cards, a plurality of hard disks with a storage capacity of 200 megabytes or more, and a plurality of CD-ROM drives ( These can be attached to file servers and used as sharable resources), multiple Ethernet connections between workstations, one file server, one backup system, one uninterruptible power supply (UPS), and One laser printer is included. Preferably, TAC 19 uses the commercially available Novell network, Oracle database server, Neuron Data Expert system, and Windows 3.1 software running on all PCs. The TAC 19 workstation is connected via Ethernet and operates on the Novell network.

  When connected to the site, TAC users can use the functions of 1) “Get Images”, 2) “DisplayImages”, 3) “HW Key Information”, 4) “Error Log”, and 5) “Site History”. All of these functions are displayed by on-screen buttons or icons that are accessible from the displayed screen. If possible, provide accelerator keys to use these functions for access. (As used herein, the term “Accelerator Keys” refers to keystrokes or combinations of keystrokes that can be used in place of pull-down menu commands or click-on buttons.

  Using the “Get Images” feature, TAC engineers can connect to a site and search for images. There is an option to look at the image as an icon before searching for it, but this icon is small in size and seems to be somewhat inferior in detail to the original. (The smaller the image size, the faster transfer is possible.) This TAC engineer can also search only the image header instead of the full image. The “Display Images” function allows TAC engineers to display images retrieved from the site. Once displayed, you can control the “windows level” to adjust the image parameters. The “HWKey Information” feature allows a TAC engineer to connect to a site and recall a snapshot on the screen of the key table of contents for that site. TAC engineers can scan through the site error log using the "Error Log" feature. “Site History” provides site history from data stored on site, from site information stored in TAC database 112, and from site history stored in ASSIST database 114 Is done.

  “Site History” stored on the site includes process history / status, key update information, key status, error message, system execution parameter, DTU record, and the like. The site history from the TAC database 112 includes problems encountered, their repairs, and the like. When the TAC engineer selects this option, the display area is distinguished by either color or font depending on the three sources. If necessary, the user can update the file log by connecting directly to the site from the “Site History” status.

  With a series of database server functions, the TAC database 112 maintains complete information for all sites. All of the following functions have graphing capabilities that allow the user to plot display information based on various graphs (pies, lines, bars). With the database server function, the TAC engineer scans the “Site History” log, scans the results log from one site through the previous site, and sees the history of hardware key updates for a site. , And see updates to a site selected by a field service engineer and an upgraded software version installed.

[Network protocol and communication]
As shown in FIG. 27, the network protocol of the DTU 12 is composed of three logical layers, that is, a data link layer 116, a session layer 118, and a network interface layer 119, via an optical fiber network 24 that is a physical media layer. Operate.

  After power-on, the RS232 port 60 (FIG. 11) of the microprocessor 44 is programmed to the 9600, N, 8, 1 data format, and the optical line 55 is connected to the RS232RxD and TxD pins. Thus, each DTU 12 can be accessed by the fiber optic network 24 using the standard RS232 protocol. Switching between the RS232 and SPI 62 interface formats can be controlled by software. Communication between the DTUs 12 is performed in the state of the data packet 120 as shown in FIGS.

  The DTU 12 where the data packet 120 arrives is addressed through physical media (eg, fiber optic network 24) and is initially manipulated by the network interface layer 119. Thereafter, the data link layer 116 of the DTU 12 in the reception state checks the checksum, checks the correct address, and receives the packet. When this reception is complete, DTU 12 sends the packet to its session layer. This data packet is for preamble, start of frame delimiter, destination address, source address, data length field, data field, end of frame delimiter, and cyclic redundancy check (CRC) as illustrated in FIGS. It consists of 2 bytes. The packet length is determined by examining the data length field. A validity check is then made by examining the frame start, frame end and CRC fields. The frame start and frame end data are known values. CRC validation consists of calculating the CRC on the frame excluding the CRC field and comparing it with the embedded CRC. The CRC algorithm used for the data packet 120 is based on a classic CRC hardware circuit, conventionally known as the “CRC-CCITT” polynomial (1021H). It is important to note that the CRC calculation of the data packet 120 is done in software or hardware depending on the network interface selected. The CRC of the RS232 SCI 60 interface and the parallel port 40 is calculated by software, while the CRC of the SPI62 interface is calculated by the FPGA 64 hardware circuit.

  The DTU network protocol data link frame (DNP) uses a large endian as a byte order network. For this reason, higher order bytes come to the start address. As an example, FIG. 29 shows the data length and the byte order used for the CRC field. It is important to note that this hierarchy computes the CRC using only the data portion of the frame.

Data link hierarchy
This data link layer 116 is the logically lowest layer of the protocol. The actual transfer of the data packet 120 is performed by this hierarchy. This data link layer 116 operates by receiving data from the session layer 118 and encapsulating it. As illustrated in FIG. 28, this containment includes adding an address to the data in the session hierarchy and calculating a checksum and adding it to the data. This data link layer 116 then sends the data packet 120 shown in FIG. 28 to the next DTU 12.

  The data link hierarchy 116 provides three different options for data transfer depending on the needs of a particular application. The three data transfer methods are reliable transmission that actively notifies receipt, transmission without receipt notification, and reliable transmission that slides a window.

  Reliable transmission is based on the basic technique of "positive acknowledgment by retransmission". This technique requires that the recipient communicates with the source, that is, sends back an acknowledgment message when data is received. Each time the sender sends a data packet 120, it keeps a record and waits for a receipt notification before sending the next data packet 120. The sender also sends a data packet 120 to activate a user-defined timer and retransmits the data packet 120 if the timer expires before the receipt notification arrives. Retransmission is attempted up to three times. For performance reasons, half of the time required to perform such work can be saved when a received message is delivered to a session hierarchy 118 that can send an acknowledgment and respond with a single message. The sender's data link hierarchy 116 always forwards an acknowledgment (embedded response) to the session hierarchy 118 for further processing. In this mode, it is not necessary to buffer at the node of DTU12. The handle of the received message is passed to the application. The length of this message cannot exceed a certain value of “DNP Maximum Transfer Unit”. Using this reliable transmission service (Riliable TransmissionService), Open Network, Close Network, Annotate, Invoke Address, Invoke Name, Download, Upload, and Memfill modules are implemented.

  In the case of transmission without receipt notification, the message can be transmitted by the application without waiting for receipt notification. The message is not retransmitted. The data link layer 116 can provide a simple transmission service for transmitting a message without waiting for an acknowledgment. The responsibility of the application program is to design the data packet 120 to confirm that it has arrived at the destination without error.

  The reliable transmission / window sliding technique is used for larger transmissions than transmissions made using the other transfer methods. Window sliding technique is a form of active acknowledgment and retransmission, where multiple data packets 120 are transmitted before waiting for acknowledgment. As shown in FIG. 31, instead of issuing a receipt notification for each reception of each data packet (packets 1 to 4) 120, the recipient site waits until four data packets 120 are received and spools each receipt notification. And then send an acknowledgment to the sender site. The number of data packets 120 that are not acknowledged is enforced by the window size at any given time and is limited to a small fixed number. When the sender receives a receipt notification for the first four data packets 120, the window slides by four at a certain time and the next series of data packets 120 is sent, as shown in FIG.

  The lost data packet 120 is retransmitted and an acknowledgment is made before the window slides. The sender side encodes enough information in the barter packet 120 to indicate the status to which an acknowledgment should be returned. When retransmitting the lost data packet 120, the sender side requests the receiver side to immediately send a receipt notification for each data packet 120.

  Unlike both the reliable transmission with positive acknowledgment and the non-acknowledgment transmission method, all acknowledgments are made by the data link layer 116 in this window sliding method. The sender's data link layer 116 accepts a large number of messages from its session layer 118 and the receiver's data link layer 116 passes a large number of messages to its receiver's session layer 118. If the requests are too large, the data link layer 116 divides them into individual data packets 120.

Session hierarchy
The session layer 118 is a logically higher layer on the protocol layer of the DTU network 13. This provides a protocol for two types of services required in the DTU network 13. That is, 1) the protocol service standard of the DTU network 13 for each DTU 12, and 2) a unique service determined by the type of DTU 12, such as kV, mA or dosimeter.

  The data that the session layer 118 sends to the data link layer 116 consists of two parts: the data length and the data (which includes the header in addition to the data itself). In the session hierarchy 118, only the data portion of the data packet 120 is used. As shown in FIG. 30, based on the first two bytes of the header, the session layer 118 can determine the type of service requested by the DTU 12 or requested by the DTU 12. This service includes annotations, network check diagnostics, program and module downloads, module calls, memory dumps, and DTU 12 time setting and debugging sessions.

[Network interface hierarchy]
The network interface layer 119 is responsible for data communication at the lowest level of the network, and is composed of device drivers and modules necessary for transmitting and receiving data packets 120. CRC calculation and verification is performed at this level, such as SCI 60 (RS232), SPI 62, parallel port interface 40, and packet driver.

  All data packets 120 that have a valid CRC and will be the DNP address assigned to the local node are accepted and passed to the data link hierarchy 116. A “broadcast” data packet 120 is similarly accepted. All other data packets 120 are removed (dropped) without further processing. The master DTU 34 is a separate exception and accepts the data packet 120 scheduled for the system monitor box 16 as well as the master DTU. Data packets 120 scheduled for or from the system monitor box 16 are routed across the parallel port interface 40 of the system monitor box 16.

[DTU software]
DTU software can be broadly divided into “Start Up” software that is executed when the power of the DTU 12 is turned on, and “Services” that is executed when the system monitor box 16 requests service. ”Classified as software.

  The 68HC11A0 microprocessor 44 starts executing instructions (codes) after power-on / reset. (See the microprocessor memory map in FIG. 10.) This software code is a model number manufactured by XILINX, Inc., San Jose, California. Selecting a bank of EPROM 58 that contains code for FPGA 64, such as XC3064, copying the FPGA code to FPGA chip 64, and performing self-diagnosis. Self-diagnosis begins with a memory test of the two RAM chips 56A and 56B in the DTU 12. If no defect is found during this diagnosis that disables the network, the software initializes the serial port 54 and waits for a data packet 120 appearing on that serial port 54 while going through one fast loop. This software selects bank 0 from memory 2000 chip 56A and sets up the necessary communication buffers. Data buffers 120 are received using these buffers. FIG. 33 shows the startup pseudo code.

  The FPGA 64 executes a logic function according to a program loaded in the FPGA 64 after power-on. The program can be downloaded from the system monitor box 16 to the RAM memory banks 56A-56C of the microprocessor module 44. The FPGA 64 is a memory mapped from address 0800 to OFFF (hexadecimal). The port A of the 68HC11A0 microprocessor 44 is connected to various FPGA 64 control pins. The FPGA 64 is RAM configurable, that is, the FPGA 64 configuration must be downloaded after power-on. Such a configuration program is in the EPROM 58. The initialization process involves resetting the FPGA 64 and then copying such configuration from the EPROM 58 to address 0800 (hexadecimal).

  To reset the FPGA 64, the FPGA 64 RESET (port A, bit 6) and PROGRAM DONE (port A, bit 5) pins are set low (LOW) for 6 microseconds and high (HIGH). Returned to This reset is completed when a low to high rise is detected on the pin of INIT (port A, bit 0). The configuration program is downloaded by writing one byte to address 0800 at a time. The FPGA 64 accepts data using one pin. In order to properly download such a program, the READY / BUSY pin (port A, bit 1) must be checked to see if it is “ready” before writing the next byte to the FPGA 64.

[DTU self-diagnosis]
The present invention includes an error reporting mechanism that displays any device or network defects. When a conflict occurs in the DTU 12 read / write processor, a voltage at a level that is not acceptable to the system is detected and a signal is sent to the LED 104 on the appropriate DTU 12 to notify the situation of the problem. For local diagnosis, the field service notebook 18 can also be connected directly to the RS232 terminal 55 of the DTU 12.

  When the initialization of the FPGA 64 is completed, a self-diagnosis of the DTU 12 is performed. First, a RAM memory test is performed by writing a unique pattern in each bank of the RAM chips 56A, 56B, and 56C in the DTU 12. This pattern is read back and compared. The pattern used for this test is a bank number. Since all banks are written and then read, the bank switching characteristics are tested simultaneously. If a conflict occurs during this read / write process, startup is stopped and an error is reported to LED 104.

  The battery voltage level and power supply level are then checked. If the voltage level is unacceptable, start-up stops and an error is reported to LED 104. If the voltage is low but acceptable to allow the electrical system to still function within the specified voltage range, it is reported to the system monitor box 16 but does not stop the start-up.

  The SCI interface 60 is initialized with the following settings. That is, baud rate: 9600, parity: none, stop bit: (1), and data bit: (8). The network buffer is then initialized. Two buffers are required to receive and transmit the data packet 120. These buffers are allocated from “BANK 0 RAM2000” 23A.

[DTU operation]
The “Startup” sequence is shown in FIG. 34 and is a process for initializing all DTUs 12. Each DTU 12 performs self-diagnosis and annotation when commanded by the system monitor box 16 through a master DTU 34. The part of the “power on” process is the DTU 12 annotation, in which each DTU 12 passes the command packet 122 through the DTU network 13 and confirms itself to return it to the master DTU 34.

  This annotation command enables the device configuration of the DTU network 13. At startup, all DTUs 12 determine their own status and their own SCM 50 status. At annotation time, its status and identification numbers are encapsulated and sent as part of the annotation packet 124. This identification number for DTU 12 and SCM 50 is assigned at the programming time of EPROM 58 and is stored in EPROM 58. Both numbers are useful to the software and are read at startup. A sequence number for the DTU 12 is similarly added to the annotation packet 124.

  As shown in FIG. 35, the annotation packet 124 is transmitted from the master DTU 34 through the DTU network 13, during which annotation information from each of all DTUs 12 is added to the annotation packet 124. Similarly, when the DTU 12 examines the annotation packet 124, it determines its sequence number in the DTU 12 network and uses that sequence number as its network number.

  In this annotation session, it is assumed that the fiber optic network 24 is in an open configuration and that each DTU 12 understands that it must retransmit the annotation packet 124 after adding the annotation information. Has been. The DTU memory dump command serves the ability to request a memory dump of the DTU 12 memory. When the system monitor box 16 issues a memory dump request indicating a bank to the DTU 12, the address and the total number of bytes are started for dumping. The DTU 12 responds with an image in memory.

  The system monitor box 16 can add modules and download them to the DTU 12. The download command serves to download the program module to any bank of RAM chips on the DTU 12. Bank, start address and number of bytes are specified. The module call command is a method for instructing to execute the module downloaded to the RAM memory of the DTU 12 in which the system monitor box 16 is located. This command sets the DTU 12 time to the system monitor box 16 time in seconds since 1970.

  Each DTU 12 executes and provides a specific service based on the SCM 50 built in the DTU. General network services (check, open, close, annotation, DTU memory dump, download, module call and time setting commands, etc.) are provided at all DTUs 12 regardless of the specific purpose of each DTU 12. These general services are performed by DTU 12 network commands. Although the maximum number of DTUs 12 that can be placed on the network is 255, 12 is the preferred placement.

  The network check is initiated by the system monitor box 16 (via the master DTU 34). Since the optical fiber network 24 is normally closed (retransmittable), any data packet 120 sent from the master DTU 34 must be received back to the master DTU. This type of data packet 120 is set to represent that this packet is a “passing” data packet that does not require any processing or response. If this transmitted data packet 120 is returned and received by the master DTU 34, such a fiber optic network 24 is operational.

  When the network open command is used, all DTUs 12 can be instructed to disable the automatic retransmission function. Thus, DTU 12 retransmits any data packet 120 that is not addressed to that DTU. The annotation packet 124 is an exception as described above. The network close command can be set to enable the automatic retransmission function by giving a command to all the DTUs 12.

  Depending on the service requested by a particular DTU 12, the system monitor box 16 dynamically downloads the appropriate software module to that DTU 12 after network annotation to set the DTU 12 function. For this reason, each DTU 12 attached to a separate device has a specific software package and execution module that match its function.

  For example, the execution module in the kV, mA DTU 76 waits for a request from the system monitor box 16 and samples either kV or mA. When this request is received, its analog port (pin 0 for kV and pin 1 for mA) is sampled and its value is returned in the response data packet 120. Similarly, the execution module of the PMT DTU 80 waits for a request from the system monitor box 16 and samples the PMT voltage. When this request is received, its analog port (pin 0) is sampled and its value is returned in the response data packet 120.

  The software module of the master DTU 34 has a parallel port 40A, and the master DTU 34 communicates with the system monitor box 16 through this port. The master DTU 34 waits for a strobe signal received from the system monitor box LPT port 40 from the system monitor box 16 and reads 8 bits (1 byte). When the read byte becomes one frame, this frame is passed through the optical fiber network 24. This reverse transfer is the same except that half of one byte is transferred at a time.

[System operation]
The user interface interposed between the field service notebook 18 and the system monitor box 16 is achieved by the GUI 22, which is issued by Toshiba America Medical Systems, Inc., located in Tustin, California. Toshiba's in-house software program “Smartbook” is preferred. This smart book was developed on a commercially available software package known as “Multi Media Toolbook” (“Toolbook”) produced by Asymetrix, Inc., located in Bellevue, Washington. When using a smart book, a field service engineer can access the diagnostic network system 10 of the present invention from his / her field service notebook 18 after permission has been granted to him. Through the pull-down menu options provided by the smart book (examples shown in FIGS. 36-40), field service engineers have access to a number of options.

  The field service engineer can immediately connect the field service notebook 18 to the system monitor box 16, collects data through the serial port 108 using the smart book software, and expert data on the system monitor box 16. The system 115 is activated. FIG. 41 illustrates the symbols on the sequence and the following options available to the field service engineer. Initially, an Ethernet connection is made between the field service notebook 18 and the system monitor box 16 (step 140).

  To launch the smart book tool, the field service engineer plugs the customized hardware key 100 into the parallel port 106 of his notebook (step 142). This hardware key 100 allows user access to the diagnostic network system 10 and incorporates an expiration time therein. If this key has not expired, the smart book launches a login screen (not shown) that displays a username and password prompt.

  Once connected and secure access is confirmed, the field service engineer notifies the diagnosis network system 10 of the present invention mounted on the system monitor box 16 to start diagnosis (step 144). FIG. 36 illustrates a typical screen image initially provided to a field service engineer and includes a graphical user interface main menu 22 and a status bar 134. The main menu 22 presents a number of menu options on the menu bar that include device configuration 126, system diagnostics 128, view 130, and utilities. 126 is included.

  A status bar 134 (FIG. 36) on each screen indicates whether the site has received any new mail since the last time the user logged in, and a system status area 136 is a blood vessel. Represents the current state of the imaging system, a Warning or Emergency Error area 138 indicates a message that requires user attention, and a Process area 140 indicates a process that is currently running. indicate. When the user logs in, a status bar 134 is displayed with all subsequent screens. This allows the user to access key information regardless of activity. Similarly, this provides consistency between screens and simplifies the process familiar to the user.

  Next, various other options in the main menu 22 will be described in more detail. Referring to FIG. 41, a device configuration option 126 allows the user to perform an initial device configuration and then to perform any re-device configuration required at a later stage. During installation, the user must configure the site 146, the X-ray system 148, and the DTU network 13 (step 150). After installation, only the DTU network 13 may need to be reconfigured (see step 152). This re-instrument configuration is required each time the DTU 12 is moved to a different test position.

  In the site configuration (step 146), the user enters site-specific information stored in the system monitor box database 110 and TAC 19. An X-ray configuration option (step 148) allows the user to enter information about any system component that needs to be replaced. Selecting an X-ray equipment configuration option displays a still picture of the X-ray room on the screen of the field service notebook, showing the various components that make up the vascular imaging system 14. The root bar display of the various components of the X-ray system is made as well. Using this display, the user can select specific components that make up the vascular imaging system 14 at such sites. These selections are located in predetermined locations on the display screen of the field service notebook 18 that forms the system equipment configuration unique to this site. This specific device configuration is saved in the system monitor database 110.

  A replaceable component has a hot area in which its picture, current part number, model number, and serial number of that component are displayed when selected (clicked on). If such a special component is not in the system monitor box database 110, its serial number field is blank and the user is prompted to type in the serial number of the new component to install. A bar code reader 102 (FIG. 14) that scans the serial number can also be used to reduce the possibility of errors. Once this serial number is entered, the serial number, model number, and part number are automatically cross-checked to ensure that the combination is in the TAC database 112. Any discrepancies are communicated to the field service engineer via an e-mail message sent by the TAC to the site and displayed in the status bar area 138. Thereafter, whenever a field service engineer logs into the site, an indication of a mismatch is displayed in the “working and e-mail” area 138 of the status bar. The component part descriptions and their associated model / serial numbers are automatically updated in the system monitor box database 110 and the TAC database 112.

  When the “VASPAC Configuration” option is selected from the menu bar of the device configuration 126, another submenu is launched (see FIG. 41). This menu lists the post-install equipment configurations most common to a particular site and provides a menu of accessory tools. A device configuration screen (Configuration screen) is displayed on the field service notebook, and this screen displays a picture of the X-ray room in which the test position is marked and a tool bar showing various DTUs 12. Therefore, the user drags and drops the DTU 12 to various test positions on the display picture corresponding to the DTU arrangement on the system. If a non-conforming DTU is dragged to the test position, an inconsistent flag is raised as an error and no such opponent is allowed. For example, the kV, mA DTU 76 cannot be used in place of the dosimeter DTU 38. The user has the ability to tailor the DTU 12 to the customer, add it and delete it from this toolbar to adapt its software configuration to the actual physical instrument configuration of the vascular imaging system 14.

  Multimedia accessories connected to the diagnostic network system by selecting “Accessories” allow the user to use the diagnostic network system with available hardware such as a camera, sound board, or video coupled to the vascular imaging system 14. You can contact the wear. Hardware dependent functions that are not identified as being available are turned off. In the operation of the blood vessel imaging system, critical hardware cannot be selected. That is, if the vascular imaging system does not operate without it, its function will not be stopped.

  Selecting the “Systems Diagnostics” option 128 on the main menu (shown in FIG. 41) provides the user with the most common troubleshooting tool associated with the vascular imaging system 14. This “SystemsDiagnostics” option 128 allows field service engineers to calibrate, perform preventive maintenance, perform troubleshooting, observe system-specific component lists, replace parts on the system, Alternatively, optimal characteristic criteria can be generated so that the diagnostic network system 10 can be returned to a setting state that the customer feels will provide the best image. By selecting the “Systems Diagnostics” option 128, the processing procedure as shown in FIGS. 15 and 18 to 26 can be executed. A sample menu screen from a smart book (SmartBook) showing access to typical processing procedures such as “Resolution“ Resolution ”and“ Half Value Layer ”is shown in FIGS. 39 and 40.

  When the user selects “Systems Diagnostics” 128, a picture of the vascular imaging system 14 is displayed on the screen of the field service notebook 18 as shown in FIG. All selectable components of such a vascular imaging system 14 are identified as buttons, and action buttons are under the calibration status bar 134, preventive maintenance 156, troubleshooting 158, components 160, snapshot 162, and replacement 164. Placed. For this reason, when the user desires to calibrate the X-ray tube, the X-ray tube button and the calibrate button are selected. On-screen instructions consisting of text, flowcharts, and / or video chips are then displayed on the screen to assist the user in completing the calibration process.

  For example, if the field service engineer selects “trouble shoot”, the diagnostic network system 10 of the present invention guides the user through the evaluation process and displays online, information and suggestions, generally shown in FIG. (See also FIG. 15 and FIGS. 18-26).

  Selecting the “View” 130 option (FIG. 41) allows the field service engineer access to either “Mail” 166 or the online X-ray “Manuals” 168. Selecting “Mail” 166 allows the field service engineer to view and respond to newly saved messages for the site or view the latest information on the TAC 19 document. A field service engineer who has selected the “Manuals” 168 option can access X-ray technical manuals stored in the CD-ROM storage device 94. These on-screen manuals include text, flowcharts, and both, as well as animated video chip instructions. A field service engineer can scan through the technical data and view the associated video chip, plus zooming on a component found in another picture to get a list of sub-components You will be guided step by step through the repair or maintenance process. Text and even video segments of the screen are associated with each other.

  The “Utilities” 132 option shown in FIGS. 41 and 43, 44 and 45 allows the field service engineer to view the site history 170, which results in past and current site results, past systems. It is possible to consider the problem (trouble), how the problem was repaired, and the error log 178. The analysis log of the past result is stored in the system monitor database 110 in a configurable result log (Results Log) state, and the overflow amount is automatically sent to the TAC database 112. If the field service engineer can refer to a repair method for a similar problem that has previously occurred, the result log information can be used to reduce the repair time. The current system status such as logged errors, current activity, and files spooled to be sent to TAC 19 can be viewed as well.

  The Fixes Log 176 contains a history of all problems encountered at the site and how the problems were repaired. An entire log is also stored in the database 110 of the system monitor box, and a copy of the log is also stored in the TAC database 112. Updates to the on-site database are automatically and electrically sent to the TAC database 112.

  The Error Log 178 contains a list of errors in the vascular imaging system 14 logged at that site. The size of the error log is configurable, and overflow error log information is automatically sent to the TAC database 112. The user can display an error. That is, it is logged within a range of time, at a certain level, at a certain number / string, and by a specific process. The user can also turn off certain fields while displaying all or a subset of the error log 178. For example, once all errors associated with a level have been pulled, the field can be turned off and more information can be displayed per line. The error may be one of three levels: “Operator”, “Service” and “Debugging”. This level is communicated to the user by being displayed. For example, when the field service engineer displays the error log 178, all errors at the operator and service level, except for the debugging level, are displayed. However, when the top user logs in, all levels of errors are displayed.

  Through the “Status” utility 172, the user can log errors 180 in the current session, a log 182 of activity that occurred in the current session, a file 184 spooled (queued) to be sent to the TAC 19, and The current operating state of the diagnostic network system 10 can be viewed, including the state 186 of the hardware key 100. This Status Error Log 180 is the same as the Error Site History Log 178, and has the "operator", "inspection repair", and "debugging" viewing capabilities. )have. The Activity Log 182 has a date and time stamp, a logging process name, and a message string. The user can search through the log and retrieve the activity logged by a specific process. This activity log 182 is configurable in size. The overflow is automatically sent to the TAC database 112. By selecting the spool 184, the files queued to be sent to the TAC database 112 can be displayed. The information displayed with each entry includes the name of the process that queued the file, the date and time that the entry was spooled, the date and time that the entry is scheduled to be sent, the destination (where the file is sent), the expected Includes transfer time, entry's current state (active or pending), and file size. The user can edit the spool (queue) by adding or deleting entries. The added entry has a “Send Immediately” option configurable by the user or a “Schedule to be sent at <time>” option. By default, the added entry is scheduled at the end of the current list.

  The field service engineer also has the option of running various self-diagnostic tests with the smart book to check the following key functions: That is, self-diagnosis for the Ethernet connection 20 between the field service notebook 18 and the system monitor box 16, the connection between the system monitor box 16 and the master DTU 34, the optical fiber network 24, and the system monitor box 16. . Thus, one tool performs various inspection and repair functions.

[Example of development of the present invention]
FIG. 46 and FIG. 47 respectively show system blocks of an expanded example in which the above-described diagnostic network system is further expanded.

  The diagnosis network system shown in FIG. 46 is obtained by connecting a plurality of sites 902a,..., 902c and one TAC 903 via a network 901 (for example, INDS). Each of the plurality of sites 902a,..., 902c has a medical modality that performs a single function by connecting a number of various modules (corresponding to devices or components of the present invention) to each other, as in the above-described embodiment. Has been. Of the plurality of sites 902a,..., 902c, for example, one site 902a is a site of a magnetic resonance (MR) imaging system, another site 902b is a site of an X-ray CT scanner, and the remaining site 902c is a blood vessel. This is the site of an imaging system (also called an angio system). A DTU is installed in each module of each medical modality, and this DTU is incorporated in the same or similar network as described above. In addition to the workstation (WS), the TAC 902 includes an FTP (File Transfer Protocol) server and field engineer notebook used when sending information from each site to the file server (File Server) via the hub (HUB). An access server (ACCESS) that is used when connected to access information of the file server is provided.

  Accordingly, the plurality of sites 902a,..., 902c can individually communicate with the common TAC 902, and can be operated in the same or similar manner as described above. If the TAC is used in common at a plurality of sites as described above, the cost for constructing and operating the TAC can be reduced. In addition, it is possible to provide a diagnostic network system that can deal with various types of modalities of a plurality of sites in a general manner.

  The number of sites and the types of modalities are not limited to those shown in FIG. For example, two sites may be used, or four or more sites may be connected. The type of modality may be any type, for example, an X-ray TV apparatus, a nuclear medicine diagnostic apparatus, or a biomagnetic field measurement apparatus using a SQUID element.

  The diagnostic network system shown in FIG. 47 is a further development of the system shown in FIG. That is, the system shown in FIG. 46 is installed in two systems, and the networks are connected to each other to enable communication in both directions or in one direction. In the figure, reference numerals 901 and 911 denote networks, reference numerals 902a, ..., 902f and 912a, ..., 912c denote sites where medical modalities are installed, and reference numerals 903, 913a, and 913b denote TACs, respectively. One of the networks 901 and 911 is an INDS line, for example, and the other is an analog transmission line, for example, which are connected to each other. In particular, one network 911 is characterized in that a plurality of (here, two) TACs are connected.

  In the case of a diagnostic network system in which networks are connected in this way, the TAC 902 of one network 901 can be configured to be directly accessible to the TACs 912a and 912b of the partner network 911, and a wide range of information necessary for modality testing can be obtained . Access in the opposite direction can also be configured. For this reason, a system directly connected to one network is constructed in, for example, a domestic region (or one region in the country), and a system directly connected to the other network is constructed in an overseas region (or another region in the country). A wide-area diagnostic network system can be provided. As another embodiment, when connecting networks in this way, three or more networks may be connected to each other.

  The modularized system that can be a diagnostic target of the diagnostic network system is not necessarily limited to the medical modality as described above, and may be a system in which a plurality of module devices are connected to each other to exhibit a specific function. Any system can be used, and the same effect as the above-described embodiment can be obtained.

  According to the present invention, there is provided a diagnostic network system capable of monitoring, maintaining (inspecting) and repairing a modularized system such as a blood vessel imaging system more easily, at low cost and with high reliability. Can be provided. Further, it is possible to provide a distributed test unit that can be suitably used for this diagnostic network system.

  In the distributed test unit of the present invention, the cost of monitoring, maintenance, and inspection can be significantly reduced, and a reliable problem solution can be presented when a trouble occurs. In addition, the field service engineers who maintain and inspect the modular system have fewer items, which is convenient and can improve mobility. Furthermore, it is possible to eliminate or reduce trial and error factors when diagnosing troubles (problems) in the modularized system, efficiently presenting a problem solution, and contributing to cost reduction of diagnosis. Further, even an experienced field service engineer can present an accurate solution to a trouble of a modular system that occurs in a difficult-to-solve manner. Furthermore, after maintenance, inspection, and troubleshooting, the modularized system can be easily returned to the previous optimum performance state, which can also reduce the total time and labor for maintenance and the like. In addition, the performance status of the modular system can be easily and reliably monitored online to improve the reliability of system management.

  Further, according to the present invention, when the system including a plurality of devices is a vascular imaging system, a network having a DTU connected to a selected device (dosimeter, control console, etc.) of the vascular imaging system is used. The DTU collects the data and forwards the data to the system monitor. A field service engineer connects a field service notebook (laptop computer) to the system monitor to access data collected by the DTU. Using this collected data, an accurate measure of system performance that can be easily monitored and replayed is created, and an optimal performance level is provided based on preset criteria. The system monitor's ability to store an electronic database provides field service engineers with support systems and reference materials, including component lists, manuals, and current software releases, which enable rapid vascular imaging systems. Less troublesome and more accurate repairs are possible.

  The present invention provides a more automated system that reduces the probability of errors that occur during manual data transfer, and requires technical support that must be taken to the site by hard copy support and field service engineers. The amount of data can be reduced and the necessary analysis of performance data can be performed with high accuracy by the system monitor, thus reducing human error in diagnosis and repair.

  Such a diagnostic network system can improve troubleshooting and repair efficiency and reduce downtime, thereby reducing costs and improving customer satisfaction. Since the test network system can also be tested non-invasively to the system under test (eg, a vascular imaging system), for example, data can be collected from a predetermined test location while the system under test is in use. This allows field service engineers to detect and correct system performance degradation in a prior learning manner, for example, before the vascular imaging system goes down.

  You can also use the off-site Technical Assistance Center (TAC) to remotely contact the system monitor, access the DTU network to check the system operating status, and update the information stored in the system monitor .

  According to the present invention, the evaluation time can also be shortened by automation. The diagnostic system of the present invention employs an expert system, and this expert system has software processed by a system monitor processor, and the data collected and stored from the DTU is analyzed by this software processing. Expert systems can more quickly refer to similar problem situations in the past and recall solutions. This expert system can therefore give field service engineers an indication of where and how to solve such a system. The expert system also proactively takes the wrong steps and directs field service engineers to alternative correct solutions. This reduces the time-consuming guesswork and trial and error associated with normal repair processes and allows for faster repair or adjustment of the vascular imaging system.

10 Diagnostic Network System 12 DTU (Distributed Test Unit)
13 DTU network 14 Vascular X-ray imaging system 15 C-arm 16 System monitor box 17 Patient table 18 Field engineer knot book 19 TAC (technical assistance sensor)
20 Ethernet connection 24 Optical fiber cable 28 Dosimeter 30 Console 32 Control panel 34 Master DTU
36 Multi-pin cable 38 Dosimeter DTU
40A Parallel port 40 LPT port 46 MM (microprocessor module)
48 PM (Power Module)
50 SCM (Sample Control Module)
76 kV, mA DTU
78 High Voltage Transformer 80 PMT DTU
88 Console DTU
104 LED

Claims (5)

In a diagnostic network system that communicates with multiple devices,
A plurality of distributed test units that communicate independently with each of the associated devices of the plurality of devices to constantly collect information regarding the operational state of the devices;
A master distributed test unit;
A network in which the master distributed test unit and the plurality of distributed test units are connected to each other via a communication medium to enable transmission of information;
A system monitor unit that communicates with the plurality of distributed test units via the master distributed test unit;
A user interface that communicates with the system monitor unit and allows a user to communicate with each of the plurality of distributed test units; and
The system monitor unit is
A control unit for collecting information on the operating state from the plurality of distributed test units;
A database for storing editing information edited based on information on the operation information collected from the plurality of distributed test units;
A means for constantly analyzing whether or not the plurality of devices need to be repaired by analyzing the collected information, and inspection and repair of the plurality of devices are required in accordance with communication with the user interface. A diagnostic network system comprising: a diagnostic unit having a tool necessary for troubleshooting a device and means for indicating an inspection / repair processing procedure. The diagnostic network system according to claim 1, wherein a system including the plurality of distributed test units, the master distributed test unit, the network, and the system monitor unit is individually connected to a plurality of medical modalities. The diagnostic network system according to claim 2, wherein the plurality of medical modalities include at least one type of medical modality among a vascular X-ray imaging system, an X-ray CT scanner, and a magnetic resonance imaging system. The plurality of distributed test units are attached to a desired test position of each of the plurality of devices, and have a configuration of continuously collecting operation data of the devices at the test positions as information on the operation state. Item 2. The diagnostic network system according to Item 1. The diagnostic network system according to claim 4, wherein the plurality of devices are a plurality of devices constituting the same medical modality.