Embedded systems have revolutionised consumer products. However, defects in these devices also open up new avenues of litigation against manufacturers. Joel Smith and Patrick Cleary of Bowman and Brooke explain how an accurate understanding of embedded systems is essential for effective defence against claims.
A prematurely born infant is laid to bed. Per her physician’s instructions, she is connected to a breathing monitor. This device continuously monitors her breathing pattern while she sleeps. The monitor contains an alarm system which is supposed to emit a loud sound if she fails to breathe properly. This remote monitoring function gives her parents the peace of mind to sleep while their infant sleeps, knowing that the alarm will detect any breathing abnormalities.
Tragically, the infant passes away during the night from sleep apnoea-related hypoxia. The distraught parents testify that they did not hear any alarm. Graves v CAS, 735 S.E.2d 650 (S.C. 2012).
During litigation, plaintiffs’ experts testify that the embedded systems in the breathing monitor were defectively designed, failed to detect the infant’s stopped breathing and failed to sound the alarm. While they cannot identify a specific defect that caused the failure to detect the stopped breathing and failure to sound the alarm, they testify defects led to the infant’s death. The plaintiffs argue that the alleged malfunction of the monitor is sufficient proof to establish liability. They testify that the embedded systems failed to comply with the international guidelines for embedded systems.
What Are Embedded Systems?
Embedded systems are specifically designed electronics that convert inputs into changes in how a device operates. The electronics are entirely encapsulated within the device, and the electronics perform only predefined tasks with narrow specific requirements. Embedded systems are designed for a specific application(s) and to do that application constantly, accurately and reliably.
A simple embedded system is a digital controller for an air conditioner, where the user can select a target room temperature. By itself, the controller cannot change the temperature of the room. However, the controller receives input from temperature gauges in the room and is connected to the air conditioner. If a user commands a lower temperature, the controller sends a command to the air conditioner to turn on. The device in the air conditioner that turns on or off is the actuator. The controller constantly receives the current temperature in the room. When the temperature gauges measure that the actual temperature is the same as the targeted temperature, the controller commands the air conditioner to turn off. The digital controller contains the hardware that processes the temperature inputs and commands the air conditioner to turn on or off, as well as the software that calculates the room temperature and determines whether the air conditioner should be on or off. Every element of the system must operate in concert to affect the room temperature.
Embedded Systems in Products
Embedded systems are in nearly every consumer product, ranging from medical devices to smart appliances to automobiles. Embedded systems allow for continuous data monitoring, minute adjustments to the product for better operation and for remote control of products.
An example of a medical device that uses an embedded system is a pacemaker. The pacemaker measures a patient’s heartbeat through sensors (the input) the software in the pacemaker determines the optimal heartbeat and sends a command to electrical impulse generator (actuator).The generator delivers a low voltage pulse to the heart ventricle. The pacemaker constantly measures the actual heartbeat to deliver the optimal electrical pulse to the ventricles. All of the system components must operate in concert to provide the proper heartbeat control.
The software within the pacemaker is optimised to provide the appropriate electrical pulse while maximising the pacemaker battery life. Even small changes in the pacemaker software can provide minute benefits in battery discharge, extending battery life by months or years.
Types of Embedded Systems Claims
We have seen four primary types of claims based on alleged embedded system defects.
The first is that the embedded system malfunctioned, leading to injury or death. An example of this type of claim is seen in Dalton v Animas Corporation, where the plaintiff alleged her insulin pump released an excessive amount of insulin. 913 F.Supp.2d 370 (W.D. Ky. 2012). The plaintiff did not allege a specific defect that would cause the pump to release an excessive amount of insulin, but made general allegations that the pump failed because an excess of insulin was released into her body.
The second are consumer class actions based on the potential for the system to fail. These claims are often brought in consolidated actions, combining product liability and economic loss actions.
The third types of claims are failure to perform as advertised claims or failure to meet performance claims. An example of these types of cases would be pacemaker battery premature depletion claims. The power consumption of lithium implantable pacemaker is controlled by an embedded system, and pacemaker batteries have a variable lifespan. A physician may inform a patient that a battery has a five-to-10-year lifespan, but the battery may deplete in three years, necessitating replacement.
The final type involves hacking claims. Hackers could allegedly take external control of consumer products through their electronic connections. See, for example, Cahen et al v Toyota Motor Corporation et al, case number 3:15-cv-01104, in the US District Court for the Northern District of California. Allegations may involve hackers impacting data security and privacy controls, or gaining unauthorised external access to information.
Expected Theories of Defect
In our experience, there are three potential defect theories involving embedded systems.
The first are specific claims of defect, focused on specific product features that cause the alleged malfunction. These claims often focus on specific lines of software and the purported system response if the software operated as written during normal operation. For example, plaintiffs might point to a specific line of software code that they allege caused the condition, but that the manufacturer did not test to evaluate its affects. These types of claims often assert that one cannot fully test every possibility of how the system will fail, but the system has the known potential to operate in the way plaintiff alleged it failed.
The second are claims that the embedded system did not comply with industry norms for designing and testing safety-critical embedded systems. We have seen plaintiffs’ experts allege the embedded system software is overly complex and “spaghetti-like” or that it used software features that they would not recommend. These types of claims will not focus on specific defects in the embedded system, but will argue that deviations or differences from “accepted” standards necessarily lead to defects in the software, causing injury and harm.
For example, the FDA has two guidance standards for medical device software: General Principles of Software Validation and Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices. These standards provide guidance on the software development process, from risk assessment, testing protocols, development process verification and documentation created during the development process. Importantly, they do not provide rigid acceptance criteria for software in medical devices.
The final claims of defect centre on the malfunction doctrine, as discussed in the Restatement Third:
It may be inferred that the harm sustained by the plaintiff was caused by a product defect existing at the time of sale or distribution, without proof of a specific defect, when the incident that harmed the plaintiff: (a) was of a kind that ordinarily occurs as a result of product defect; and (b) was not, in the particular case, solely the result of causes other than product defect existing at the time of sale or distribution. Restatement (Third) of Torts, Product Liability § 3 Circumstantial Evidence Supporting Inference of Product Defect, p.111 (1998).
These types of defect claims assert that the mere fact of injury creates the inference that the device failed because of a defective design. We have seen plaintiffs argue that “all electronics” fail and that because a device uses electronics, it can fail, leading to plaintiffs’ injuries.
Challenges in Defending Embedded Systems Cases
Defending an embedded systems case presents several challenges beyond a traditional products liability action.
First, judges and juries are familiar with electronics, and more importantly are familiar with their laptops freezing or their smartphone dropping their calls. The idea that electronics can fail and can fail at arbitrary and random times is not a foreign concept. Judges and juries are all too familiar with their consumer electronics working properly, acting abnormally, and then working properly after being reset. The malfunction doctrine gives a legal framework on which a judge can allow litigation to proceed beyond dispositive motions even if a specific defect is never identified.
Second, there are cases where embedded systems abnormalities have led to harm. One well-known case involved abnormally high doses of radiation from the Therac-25 radiation therapy device. A software defect in the device created the possibility that a high-power electron beam would be accidentally activated instead of the intended low-power beam. Several patients were killed before the fault was identified.
Third, many embedded systems do not record whether an abnormality occurred. The device may operate normally over its life, but there is no definitive proof to show that it operated normally when the event occurred. In CAS v Graves, the breathing monitor had an internal record of the infant’s breathing and an alarm register. But not every embedded system has event recording capabilities.
Fourth, there are no rigid standards for embedded system development, but only guidance manuals. Developing embedded systems builds from the expertise of specialised engineers, who necessarily make subjective judgements about the scope and breadth of risk assessment and verification and validation testing. Plaintiffs’ experts can always opine that there is a better approach. The FDA guidelines give credence to these arguments, stating that: “Software verification and validation are difficult because a developer cannot test forever, and it is hard to know how much evidence is enough.
Practice Tips for Defending Embedded System Cases
Defending embedded system cases begins with understanding how the system is supposed to work, how the system can fail, and the limits of what the system can do. Knowing this helps frame the potential types of claims and cases which could result from an embedded system failure. This analysis requires learning how the system was designed, validated and verified. It is important to know how the manufacturer ensured “the particular requirements implemented through software can be consistently fulfilled”. Having strong corporate witnesses can help tell that story.
After learning how the device works, the next step is evaluating how the device operated in the subject event. Are there facts that suggest an alternative or more likely cause? In CAS v Graves, evidence was strong that the parents slept through the alarm. Knowing an alternative explanation helps provide the framework for arguing that the malfunction doctrine is inappropriate for a specific case and that electronics were not the cause.
Knowing how the device works and can fail provides the framework for expert witness depositions, Daubert motions, and other court filings. Insist that plaintiff identify a specific defect and link that specific defect to the particular incident. General allegations of defect, differences from guidelines and poor software quality should not establish a basis for liability. Nor should they establish a sound methodology and reliable basis for the admission of expert witness testimony under Rule 702 and Daubert. Plaintiffs’ experts must admit the limitations of the guidelines and may even testify that they themselves deviate from the guidelines in order to provide a better product.
Embedded systems in consumer products enable better operation, new functions and allow them to do things never before imagined. But claims of embedded system defects open up new avenues of litigation against manufacturers, ranging from product liability to class action to consumer privacy litigation. Defending these actions requires an understanding of what embedded systems are, how the specific embedded system was developed, tested and validated, and how the embedded system operated in the subject event. Having this understanding will provide the underpinnings for a vigorous and effective defence against the malfunction doctrine and general claims that all electronics can fail.