Just Remember: If You Cut Off Your Finger, Tell Your Wife the Firmware Did It.

Earlier this week in Jack Ganssle’s regular Break Points column on embedded.com, Jack highlighted the story of a careless table saw operator, who parlayed his ignorance into a big payday at the cost of the saw manufacturer, and its relevance to a proposed software liability law. In the end, the OEM was found liable for the operator’s injuries because, even though he was disregarding the specified operating procedures and safety protocols, the OEM did not include an emergency flesh-sensing shutdown feature that a competitor had included within a different product. In effect (and I admit I say this with a hint of sensationalism), the OEM was penalized for their competitor’s innovation.

(By the way, if any of you saw the recent remake of the movie Arthur, you no doubt have additional appreciation of the potential applications of table saw emergency shutdown technology)

The article makes the case that the potential liability arising from embedded software functioning incorrectly – or even functioning correctly under an unforeseen set of circumstances – should compel OEMs across the embedded industry to pay more attention to the quality of the software code. So basically the increasing amount of device sophistication and functionality driven by software also simultaneously ups the industry’s standard/minimum duty of care.

Clearly, OEMs can implement some best practices to help improve their code quality such as the use of standardized development processes, coding standards, and automated test tools. However, given that an increasing amount of embedded software content is being created by third parties (commercial IP, open source components, ODM/tier 2 OEM subsystems, etc), OEMs will need to go to even greater lengths going forward to audit and ensure the functionality of the software from its entire supply chain. Ultimately, in this increasingly litigious environment, any liability posed on the OEM community will also likely be passed downstream – at least in part – to their supply chain partners in a series of finger pointing, scapegoating, and countersuits.

So what else can/should OEMs (or other software stack contributors) do to at least limit their exposure to risk?

For one, IP management tools such as those from Black Duck or Palamida can help establish software component lineage, but can stop short of providing the documentations of asset functionality – especially as it pertains to their functionality when integrated with in-house IP. Additionally, this trend likely puts even greater pressure/importance on software testing – as well as specifically the test scripting/design process for dynamic testing. If all else fails (or perhaps as a parallel contingency plan), OEMs can always fall back on the old strategy of beefing up their in-house legal staff and conspiring with competitors to lobby Washington for protective legislation…