Serial communications protocol for safety critical systems

• US 8,312,098 B2
• Filed: 11/09/2006
• Issued: 11/13/2012
• Est. Priority Date: 11/09/2006
• Status: Active Grant

• Current Assignee: Johnson & Johnson Surgical Vision, Inc. (Johnson & Johnson)
• Original Assignee: Abbott Medical Optics Incorporated (Johnson & Johnson)
• Inventors: Claus, Michael J., Nguyen, Hao V.
• Primary Examiner(s): Patel, Ashok
• Assistant Examiner(s): EDWARDS, LINGLAN E
• Application Number:
  US11/558,429
• Publication Number:
  US 20080115146A1
• Time in Patent Office: 2,196 Days
• Field of Search: 709/208, 709/209, 370/252, 719/313
• US Class Current: 709/208
• CPC Class Codes: H04L 43/08 Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
• CPC Class Codes: H04L 43/16 Threshold monitoring
• CPC Class Codes: H04L 67/12 specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
• CPC Class Codes: H04L 69/32 Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level

Abstract

A method and system of establishing communications between at least two independent software modules in a safety critical system, such as a medical system, is provided. The design comprises providing a media connection between software modules, wherein the software modules employ a communications protocol and participate in a bi-directional master-slave relationship between a master module and a slave module. The design further comprises sending an arbitrary length of data between the master and slave modules, wherein the arbitrary length of data is used by the master module to control and obtain status from the slave module, and sending arbitrary data further enables the slave module to return data and status information to the master module. The design also employs a safety critical communications watchdog between the master and slave modules, wherein the safety critical communications watchdog monitors communications quality between the master and slave modules. The protocol comprises bytes transmitted using a packet consisting of a start indication, a message identifier, an optional service identifier, a class identifier, an arbitrary length of data pertinent to the medical device comprising optional data, a checksum, and a checksum complement.

Claims

1. A method for establishing communications between at least two independent software modules in a safety critical system, comprising:

providing a media connection between software modules, wherein the software modules employ a communications protocol and participate in a bi-directional master-slave relationship between a master module and a slave module;

sending messages from said master module to said slave module and from said slave module to said master module, each message comprising an arbitrary length of data comprising optional data, enabling the master module and slave module to detect errors in each message and the master module to control and obtain status from the slave module, and the message further enables the slave module to return data and status information to the master module; and

employing a safety critical communications watchdog function between the master and slave modules, monitoring communications quality between the master and slave modules bi-directionally, wherein the safety critical communications watchdog function comprises the master module and the slave module simultaneously counting time between receiving data packets from the other module and generating a fail condition when a data packet has not been received in a predetermined amount of time,

wherein communications protocol comprises transmitting bytes in a packet consisting of;

a start indication;

a message identifier;

an optional service identifier;

a class identifier;

an arbitrary length of optional data;

a checksum; and

a checksum complement.

2. The method of claim 1, wherein said fail condition results in reduced functionality of at least one system component.

3. The method of claim 1, wherein:

the message identifier describes a type of message the packet contains;

the optional service identifier describes what is to be done with the packet; and

the class identifier describes data contained in the packet.

4. The method of claim 1, wherein the optional service identifier depends on contents of the message identifier.

5. The method of claim 1, wherein the software modules communicate over a low bandwidth media.

6. The method of claim 1, wherein employing the safety critical communications watchdog function comprises providing an expected packet rate and an interval to the software modules, wherein the interval comprises a time interval at which the software modules are to test the safety critical communications watchdog function.

7. The method of claim 1, wherein employing the safety critical communications watchdog comprises monitoring packets sent between the software modules, decreasing a counter in one software module when expected packets are not received for a period of time, and indicating safety critical actions are to be taken when the counter in the one software module decreases below a threshold.

8. A medical device system configured to manage communications therein, the system comprising:

a master device and a slave device;

wherein the master device and the slave device each comprise a plurality of software modules comprising at least two software modules; and

a media connection between the master device and the slave device;

wherein the master device and the slave device are capable of communicating via the plurality of software modules using implicit messaging, the implicit messaging comprising transmitting an implicit message containing no data object description and comprising an arbitrary length of data comprising optional data from said master device to said slave device and from said slave device to said master device to detect errors in and verify integrity of the implicit message;

wherein the plurality of software modules provide a medical event safety critical communications watchdog function to verify communications integrity over the media connection, wherein the safety critical communications watchdog function comprises the master device and the slave device simultaneously counting time between receiving data packets from the other device and generating a fail condition when a data packet has not been received in a predetermined amount of time,

wherein the bandwidth efficient communications protocol comprises bytes transmitted using a packet consisting of;

a start indication;

a message identifier;

an optional service identifier;

a class identifier;

an arbitrary length of optional data;

a checksum; and

a checksum complement.

9. The system of claim 8, wherein the fail condition results in reduced functionality of at least one medical system component.

10. The system of claim 8, wherein said arbitrary data is used by the master device to control and obtain status from the slave device, and sending arbitrary data further enables the slave device to return data and status information to the master device.

11. The system of claim 8, wherein:

the message identifier describes a type of message the packet contains;

the optional service identifier describes what is to be done with the packet; and

the class identifier describes data contained in the packet.

12. The system of claim 8, wherein the optional service identifier depends on contents of the message identifier.

13. The system of claim 8, wherein the plurality of software modules communicate over a low bandwidth media.

14. The system of claim 8, wherein employing the medical event safety critical communications watchdog comprises providing an expected packet rate and an interval to the plurality of software modules, wherein the interval comprises a time interval at which the plurality of software modules are to test the medical event safety critical communications watchdog.

15. The system of claim 8, wherein employing the medical device safety critical communications watchdog comprises monitoring packets sent between the plurality of software modules, decreasing a counter in one software module when expected packets are not received for a period of time, and indicating medical safety critical actions are to be taken when the counter in the one software module decreases below a threshold.

16. A safety critical system comprising:

a master medical device; and

a slave medical device,

wherein the devices comprise a plurality of software modules capable of communicating via a bandwidth efficient communications protocol, and wherein the communications protocol comprises bytes transmitted using a packet consisting of;

a start indication;

a message identifier;

an optional service identifier;

a class identifier;

an arbitrary length of data pertinent to the medical device comprising optional data, wherein length of the arbitrary length of data depends upon at least one of the class identifier, message identifier, and optional service identifier;

a checksum; and

a checksum complement;

and wherein the master medical device and the slave medical device each provide a medical event safety critical communications watchdog function to verify communications integrity over the media connection, wherein the safety critical communications watchdog function comprises the master medical device and the slave medical device simultaneously counting time between receiving data packets from the other medical device and generating a fail condition when a data packet has not been received in a predetermined amount of time.

17. The system of claim 16, wherein:

the message identifier describes a type of medical related message the packet contains;

the optional service identifier describes what is to be done with the packet within the medical devices; and

the class identifier describes medical device data contained in the packet.

18. The system of claim 16, wherein the optional service identifier depends on contents of the message identifier.