New Engineering Ethics: Deep Dive into the DFMEA Strategy #2
Deep Dive into the Tesla Autopilot Case:
Introduction – Engineering Ethics applied to the Tesla Autopilot Case
Let’s look at the Tesla’s “Autopilot” function from the original design intent standpoint and the way the development team implemented it. (The following information is adopted from the public news channels and analyzed for the reader’s comprehension of the Systems Engineering perspective, specifically related to the Engineering Ethics.)
“By definition the Autopilot is: the feature intended to assist drivers with steering, acceleration and braking and, despite what its name might suggest, still requires driver input and attention, including to have their hands on the wheel and to be “fully attentive”.
Launched in 2015, the software forms part of the firm’s wider vision for an autonomous driving future where human input is no longer needed at the wheel. It still requires drivers.”
Remarkably, this an example of the “production ready” marketable Vehicle Feature, which is part of the Vehicle Content as one of the most attractive elements of the vehicle assembly designs. Interestingly, the term “production ready” implies completed verification and validation activities pertinent to the intended design (function). Moreover, it is particularly significant because the content of the feature is a software (algorithm) package.
Finally, the purpose of the article is to review and compare the manufacturer’s intention and resultant implementation of the described function, along with discussion on the means used to deliver this feature of the vehicle assembly.
The OEM Engineering Ethics – the Intended Application and Verification of the Performance related to the Defined Requirements
Firstly, let’s look at the naming convention – “Autopilot”. Consequently, it is obvious that the name in its origin carries a certain ethical misalignment between the marketing name and the essence of the implementation. Conclusively, simply because by the definition given above, the driver still needs to be actively engaged in the operation of the vehicle.
Furthermore, the intent of the feature is an “assist”, not a “full autopilot” function. Moreover, even though the manual has a complete disclosure on the topic, and the driver is the “responsible” party, it is still important to point out the obvious misinformation included into the naming convention.
Secondly, let’s look at the software (package) developed with intent to abide certain logic (feature and systems requirements). However, again from the media referencing the NHTSA: it found “the prominence and scope of the feature’s controls may not be sufficient to prevent driver misuse“. This phraseology means that the integration of the software and its interfaces either:
- Possibly, did not follow the intended logic
- Alternatively, did not have proper alignment between inputs and outputs, in other words did not know what to do in some live events
- Finally, was not capable to react properly on time
Moreover, related to the verification of the high-level feature function, i.e. vehicle behavior, there are lapses which led to the 13 vehicle crashes, including occupants injuries and even death. (Information dated to April 29th, 2024.)
The Product Functional Capabilities – as Manufactured for the Consumer Experience and Utilization - Analysis
Generally, analyzing the information available, the following comes to mind:
- Firstly, it implies the necessity to educate and even train the driver or user
- Secondly, it points to necessity to investigate the fundamental logic of the implemented feature – applies all of the released software
- Thirdly, it demonstrates the lack of proper testing for the intended functionality
In addition, the most important step: to correlate the intended logic to the known crash cases, in order to understand the following:
- Fundamentally, the sufficiency of the requirements
- Sequentially, proper alignment between inputs and outputs, in terms of logical reaction by design of the algorithm
- Necessarily, the timing allowable for the reaction for the vehicle in each case
- Possibly, determine if in the known cases, there are failure modes not comprehended and not captured in the system DFMEA, consequently not even tested
Consequently, in short summary here: the consumers suffered to various degree. Sequentially, this was caused by insufficient development of requirements, followed by insufficient DFMEA, which furthermore led to the shallow development and evaluation and validation activities. Moreover, the production intended vehicles were not subjected to enough evaluation scrutiny for the final production sign off. Finally, this is clearly not Ethical on the Manufacturer’s part.
Possible considerations missed (Suggested Ethical behavior)
It is understandable that the development team acted on the information available to them. Consequently, they did a very good job on creating the vehicle assembly following the corporate goals set for them, based on the set parameters. With exception to the obvious fact that their “performance goals” were not good enough for the actual implementation of the developed product.
Furthermore, the crux of the issue lies in the initial setup of Usecases and system logic, where discrepancies between requirements and real-world crash scenarios became apparent. Moreover, the lack of a comprehensive design failure mode analysis resulted in a shortened verification cycle, raising questions about the adequacy of simulation tools employed. Sequentially, what is still unknown how many other failure modes they have missed and what is yet needs to be tested to truly have the “safe” vehicle on the road.
In addition, is there a comprehensive simulation tool, which was used for the verification of the intended functionality? What were the Usecases in the simulations? What is the correlation between the Usecases in the simulation with the Crash cases.
Generally, it’s uncertain if a comprehensive vehicle-level simulation was conducted, and the correlation between simulated use cases and actual crash scenarios remains unclear. Possibly, some type of the bench test was used to verify the connectivity related to the physical wiring and simple verification of the known inputs and outputs was run successfully. Conclusively, this is Not good enough for this level of complexity and Driver / occupants safety.
Conclusion – Engineering Ethics in Systems Engineering; Understanding the Potential Failures
In conclusion, the vehicle is not to be deemed “safe” unless proven otherwise. The way to address the public confidence is to produce and demonstrate the answers to the questions asked above in the article.
Sequentially, the proper (Ethical) Engineering development process should involve the comprehensive systemic development of the product or function, which can be simulated and verified, tested in all possible conditions. Furthermore, a simple question by the investigator: “Please show me your simulation or test documentation pertinent to this specific crash case?” may not be answered properly.
Option 1 – answer from the Manufacturer: “Yes, here is all of the proper documentation, we tested it and have results documented.” In which case, if the tested results were OK, the vehicle did not perform to the design intended. And if the test documentation shows excessive potential damage to the vehicle and occupants – does it mean that the management allowed this product on the road?
Option 2 – answer from the Manufacturer: “We have never perceived certain scenarios and never tested the vehicle in those conditions. We cannot encompass all possible scenarios.”
Demonstrably, this would be the true misalignment between the “do good” with the product promised and the reality of the development capabilities and manifestation of the lack of Engineering Ethics on part of the Manufacturer.
Additional note for the Virtualization and development of the Simulation Capabilities
Conclusively, there is an obvious necessity to engage in the development of the advance comprehensive simulation capabilities (tools) able to demo / verify all possible Usecases (scenarios) with the processing speed and necessary logic for the actual physical crash scenarios and other perceived road / environmental conditions.
References:
News source reference – Tesla Autopilot: https://ca.news.yahoo.com/tesla-autopilot-recall-probed-us-135046910.html
Engineering Ethics, general Reference: https://en.wikipedia.org/wiki/Engineering_ethics
Referencing Objectivist View on Engineering Ethics: https://georgedallen.com/upholding-objectivist-principles-navigating-basic-engineering-ethics/
Virtual Development: https://georgedallen.com/virtual-development-embracing-tomorrow-today/
Previous Articles, Engineering Ethics addressed:
https://georgedallen.com/new-engineering-ethics-fundamentals-of-product-development/
https://georgedallen.com/new-engineering-ethics-deep-dive-into-the-dfmea-strategy/
About George D. Allen Consulting:
George D. Allen Consulting is a pioneering force in driving engineering excellence and innovation within the automotive industry. Led by George D. Allen, a seasoned engineering specialist with an illustrious background in occupant safety and systems development, the company is committed to revolutionizing engineering practices for businesses on the cusp of automotive technology. With a proven track record, tailored solutions, and an unwavering commitment to staying ahead of industry trends, George D. Allen Consulting partners with organizations to create a safer, smarter, and more innovative future. For more information, visit www.GeorgeDAllen.com.
Contact:
Website: www.GeorgeDAllen.com
Email: inquiry@GeorgeDAllen.com
Phone: 248-509-4188
Unlock your engineering potential today. Connect with us for a consultation.
