Incident: Smart Car Software Failure Strands Users in Remote Areas

Published Date: 2020-02-18

Postmortem Analysis
Timeline 1. The software failure incident happened on a Valentine's Day weekend trip to northern California, as mentioned in the article [96445]. 2. Published on 2020-02-18. 3. The incident likely occurred on the weekend of Valentine's Day in 2020, which would be around February 14-16, 2020.
System 1. Gig's smart car software system failed to function properly, leading to the car becoming unusable due to a software issue [96445].
Responsible Organization 1. Gig, the car sharing startup, was responsible for causing the software failure incident as their smart car's software issue rendered the vehicle unusable, leading to the stranded situation on a remote highway [96445].
Impacted Organization 1. Users of Gig car-sharing service [96445]
Software Causes 1. The software issue on the smart car rendered it unusable due to a connectivity problem with the cloud, which required the car to be re-synced every 24 hours for security purposes [96445]. 2. The car's software could not be remotely reset as it was out of cellular service range, leading to the need for towing [96445]. 3. The car could not be re-synced easily if it was more than 50 miles outside of the "HomeZone," out of cell range, or if the vehicle was moving, indicating a limitation in the software's functionality [96445]. 4. The longer the car went without an update, the more vulnerable it became to security issues, highlighting a potential flaw in the software's update mechanism [96445]. 5. The software issue required the car to be rebooted before it could be used again, indicating a software glitch or fault [96445].
Non-software Causes 1. Poor cell service in the remote area where the car was parked, leading to the inability to remotely reset the car's software [96445]. 2. Lack of communication or awareness about the need for a radio frequency identification (RFID) card to unlock the car in areas with poor cell service [96445].
Impacts 1. Stranding of customers in remote locations without the ability to use the smart car due to a software issue, leading to inconvenience and potential safety concerns [96445]. 2. Need for multiple tow trucks, extensive phone calls to customer service, and significant time spent resolving the software issue, causing frustration and delays for the affected customers [96445]. 3. Requirement for a radio frequency identification (RFID) card to lock or unlock the car in areas with poor cell service, highlighting the need for additional hardware solutions to mitigate software failures in certain situations [96445]. 4. Impact on the reputation of the car-sharing service, with customers sharing their negative experiences on social media and news outlets, potentially leading to a loss of trust and credibility in the company [96445].
Preventions 1. Implementing a more robust software update mechanism that does not solely rely on cellular connectivity, especially in areas with poor reception, could have prevented the software failure incident [96445]. 2. Providing clearer and more prominent information to users about alternative methods, such as using a radio frequency identification (RFID) card, to lock or unlock the car in areas with poor cell service could have helped prevent such incidents [96445]. 3. Conducting thorough testing and simulations in various scenarios, including low connectivity areas, to identify and address potential software vulnerabilities before they lead to operational failures could have mitigated the risk of such incidents [96445].
Fixes 1. Implement a system where the car's software can be remotely reset even when it is out of cellular service range to prevent incidents like the one experienced on the remote highway [96445]. 2. Develop a mechanism to re-sync the car automatically even if it is more than 50 miles outside of the "HomeZone" or out of cell range to ensure the vehicle remains updated and secure [96445]. 3. Provide users with a radio frequency identification (RFID) card as an alternative method to lock or unlock the car in areas of poor cell service, ensuring they are not solely dependent on cell service or Bluetooth for car access [96445]. 4. Enhance communication with customers about the importance of Gig Cards in starting a vehicle, especially in areas with poor cell service, to prevent similar incidents in the future [96445].
References 1. Customer service representative from Gig [96445] 2. Email communication from Gig [96445] 3. Software engineer with experience in the field [96445] 4. Kate Wolffe, a reporter at KQED [96445] 5. Various Twitter users who shared their experiences [96445] 6. Reddit poster who shared a similar experience [96445] 7. The Atlantic’s Annie Lowrey [96445] 8. Spokesman from AAA Northern California, parent company of Gig [96445]

Software Taxonomy of Faults

Category Option Rationale
Recurring one_organization, multiple_organization (a) The software failure incident related to the car-sharing service provided by Gig has happened before within the same organization. The article mentions instances where users have experienced similar issues with the smart cars provided by Gig. For example, a reporter at KQED was stranded at Redwood regional park in Oakland, and another Twitter user got stranded in Muir Woods, both experiencing difficulties with the smart car's software [96445]. (b) The software failure incident related to the car-sharing service provided by Gig has also happened at other organizations or with their products and services. The article mentions a Reddit poster who shared a similar experience where his car stopped working when it lost cell service on the other side of the Golden Gate Bridge. Additionally, in September 2019, the Atlantic's Annie Lowrey wrote about getting stranded by Zipcar in a similar fashion, indicating that software-related issues are not unique to Gig but can occur with other car-sharing services as well [96445].
Phase (Design/Operation) design, operation (a) The software failure incident in the article can be attributed to the design phase. The incident occurred due to a software issue on a smart car that rendered it unusable while the users were on a trip. The car's software needed to be re-synced automatically every 24 hours for security purposes, but it couldn't be easily re-synced if it was more than 50 miles outside of the "HomeZone," out of cell range, or if the vehicle was moving. This vulnerability was highlighted by a software engineer who mentioned that the longer the car goes without an update, the more vulnerable it becomes to security issues [96445]. (b) The software failure incident can also be linked to the operation phase. The users experienced difficulties in restarting the vehicle as it needed to be synced through the cellular network. They had to make numerous calls to customer service, tow trucks were involved, and there were challenges in explaining the situation to various representatives. Ultimately, after multiple attempts and interactions with customer service, the car was finally able to start again, indicating operational challenges in resolving the software issue [96445].
Boundary (Internal/External) within_system (a) The software failure incident described in the article is primarily within the system. The failure was caused by a software issue on the smart car, which rendered it unusable when the users tried to start it after a quick hike down to the beach [96445]. The car's software needed to be remotely reset, but it couldn't be done as it was out of cellular service range, leading to the need for towing. Additionally, the car needed to be re-synced every 24 hours for security purposes, and without this re-sync, customer service agents couldn't assist remotely. The inability to re-sync the car when it was more than 50 miles outside the "HomeZone," out of cell range, or moving further contributed to the software failure incident [96445].
Nature (Human/Non-human) non-human_actions, human_actions (a) The software failure incident occurring due to non-human actions: The software issue that rendered the smart car unusable was due to a lack of cellular service range, preventing the car's software from being remotely reset [96445]. The car needed to be re-synced automatically every 24 hours to update its connection to the cloud for security purposes, but this was not possible when the vehicle was more than 50 miles outside of the designated "HomeZone", out of cell range, or in motion [96445]. The longer the car went without an update, the more vulnerable it became to security issues, highlighting a vulnerability in the software system [96445]. (b) The software failure incident occurring due to human actions: Human actions also played a role in the software failure incident. The user's decision to drive the smart car into rural California, where there was a lack of cell service, contributed to the situation [96445]. Additionally, the lack of awareness among users about the option to order a radio frequency identification (RFID) card to unlock the car in areas of poor cell service was a human factor that could have prevented the incident [96445]. The company acknowledged the need to improve communication with users about the importance of the Gig Card in such situations [96445].
Dimension (Hardware/Software) hardware, software (a) The software failure incident in the article was primarily due to contributing factors originating in hardware. The incident involved a smart car from a car-sharing startup called Gig becoming unusable on a remote highway due to a software issue. The car's software could not be remotely reset as it was out of cellular service range, and it needed to be towed back for a reboot through the cellular network [96445]. (b) The software failure incident also had contributing factors originating in software. The car's software needed to be re-synced automatically every 24 hours for security purposes, but it couldn't be easily re-synced if it was more than 50 miles outside the "HomeZone," out of cell range, or if the vehicle was moving. This vulnerability to security issues due to lack of updates is a common issue with such technology [96445].
Objective (Malicious/Non-malicious) non-malicious (a) The software failure incident described in the articles does not appear to be malicious. It was a non-malicious failure caused by a software issue in the smart car's system, which rendered the vehicle unusable [96445]. The incident was attributed to the car's software not being able to be remotely reset due to being out of cellular service range, leading to the need for the car to be towed [96445]. The failure was further exacerbated by the car's inability to re-sync with the cloud for security purposes when it was more than 50 miles outside of the designated range or out of cell range [96445]. (b) The software failure incident was non-malicious in nature, stemming from technical limitations and design flaws rather than any intentional harm. The incident highlighted the vulnerability of smart cars to software issues when they lack a dependable cell connection for updates, emphasizing the importance of maintaining connectivity for security reasons [96445]. The company involved, Gig, took steps to address the incident by offering solutions like RFID cards to mitigate similar issues in the future and improve communication with customers [96445].
Intent (Poor/Accidental Decisions) poor_decisions (a) The software failure incident described in the articles seems to be related to poor_decisions. The incident occurred when the smart car rented from Gig, a car-sharing startup, experienced a software issue that rendered it unusable on a remote highway in rural California. The issue stemmed from the fact that the car's software needed to be re-synced every 24 hours for security purposes, but it couldn't be easily re-synced if it was more than 50 miles outside of the "HomeZone", out of cell range, or if the vehicle was moving [96445]. Additionally, the incident highlighted poor decision-making in terms of communication and customer service. The company, Gig, did not effectively communicate to users the importance of ordering a radio frequency identification (RFID) card to lock or unlock the car in areas of poor cell service. This precaution was buried in the company's website and not widely known to users, leading to situations where customers were stranded due to the software issue [96445].
Capability (Incompetence/Accidental) development_incompetence, accidental (a) The software failure incident in the article seems to be related to development incompetence. The incident occurred due to a software issue on a smart car from a car-sharing startup called Gig, rendering the vehicle unusable on a remote highway [96445]. The software issue prevented the car from being started using the app on the phone, and customer service representatives mentioned that the car's software could not be remotely reset as it was out of cellular service range. Additionally, the article mentions that the car needed to update its connection to the cloud for security purposes, but this process was not possible due to being outside the designated range or moving [96445]. (b) The software failure incident could also be attributed to accidental factors. The incident occurred when the car was stopped for a quick hike, and upon returning, the phone could no longer start the car due to a software issue. This accidental situation led to the car being stranded on the side of a mountain in rural California, highlighting the unexpected consequences of the software failure [96445].
Duration temporary (a) The software failure incident described in the articles was temporary. The incident occurred when the smart car lost cell service in a remote area, rendering it unusable. The car's software needed to be re-synced with the cloud for security purposes, but this couldn't be done remotely due to the lack of cellular service. As a result, the car had to be towed back to an area with cell service to resolve the issue. It took multiple tow trucks and numerous phone calls to customer service to finally reboot the car and get it working again [96445]. (b) The software failure incident was temporary as it was caused by specific circumstances such as the loss of cell service in a remote area. The issue was not permanent and could be resolved by re-syncing the car with the cloud once it was back in an area with cell service [96445].
Behaviour crash, omission, other (a) crash: The software failure incident described in the article can be categorized as a crash. The smart car's software issue rendered the vehicle unusable, leading to the car stopping on the side of a remote highway, leaving the users stranded [96445]. (b) omission: The software failure incident can also be categorized as an omission. The car's software failed to perform its intended function of starting the vehicle after the users returned from a quick hike, leading to the need for a tow truck to reset the car [96445]. (c) timing: The software failure incident does not align with a timing failure as the system did not perform its intended functions too late or too early. The issue was more related to the system losing state and not performing its intended functions or omitting to perform its functions [96445]. (d) value: The software failure incident does not align with a value failure where the system performs its intended functions incorrectly. The issue was more related to the system crashing and not being able to start the vehicle as intended [96445]. (e) byzantine: The software failure incident does not align with a byzantine failure where the system behaves erroneously with inconsistent responses and interactions. The issue was more related to the system crashing and needing to be reset to function properly [96445]. (f) other: The software failure incident can be categorized as a failure due to the system's dependence on a cellular network for syncing and updates. The inability to re-sync the car when it was out of cell service range led to the software issue and the need for a tow truck to reset the car [96445].

IoT System Layer

Layer Option Rationale
Perception sensor, processing_unit, network_communication, embedded_software (a) sensor: The software failure incident reported in the article was related to a smart car's inability to start due to a software issue. The car's software could not be remotely reset as it was out of cellular service range, indicating a sensor-related issue where the car's sensors could not communicate properly due to lack of connectivity [96445]. (b) actuator: The incident did not specifically mention any issues related to actuators in the smart car system. (c) processing_unit: The software failure incident involved the car's software needing to be re-synced automatically every 24 hours for security purposes. Without the ability to re-sync the car, customer service agents could not remotely assist members, indicating a processing unit-related issue in maintaining the security and functionality of the system [96445]. (d) network_communication: The failure was directly related to network communication issues as the car could not be re-synced easily if it was more than 50 miles outside of the "HomeZone" or out of cell range. The car needed to update its connection to the cloud for security purposes, but being out of cell range hindered this communication, leading to the software failure incident [96445]. (e) embedded_software: The software failure incident was primarily caused by issues related to the embedded software in the smart car system. The longer the car went without an update, the more vulnerable it became to security issues, highlighting the importance of maintaining and updating the embedded software for proper functionality [96445].
Communication connectivity_level The software failure incident described in the article was related to the connectivity level of the cyber-physical system. The failure was due to the car's software issue that rendered it unusable when it lost cell service in a remote area, preventing it from being remotely reset or re-synced [96445]. The inability to re-sync the car due to being outside the "HomeZone" or out of cell range highlights a connectivity issue at the network or transport layer of the system.
Application TRUE The software failure incident described in the articles was related to the application layer of the cyber physical system. The failure was due to a software issue on a smart car from Gig, a car-sharing startup, which rendered the car unusable while the users were on a trip in northern California [96445]. The issue stemmed from the car's software not being able to be remotely reset as it was out of cellular service range, leading to the need for the car to be towed back for a reboot [96445]. Additionally, the software engineer mentioned in the article highlighted that the longer the car goes without an update, the more vulnerable it becomes to security issues, indicating a software-related vulnerability [96445].

Other Details

Category Option Rationale
Consequence delay (a) death: People lost their lives due to the software failure (b) harm: People were physically harmed due to the software failure (c) basic: People's access to food or shelter was impacted because of the software failure (d) property: People's material goods, money, or data was impacted due to the software failure (e) delay: People had to postpone an activity due to the software failure (f) non-human: Non-human entities were impacted due to the software failure (g) no_consequence: There were no real observed consequences of the software failure (h) theoretical_consequence: There were potential consequences discussed of the software failure that did not occur (i) other: Was there consequence(s) of the software failure not described in the (a to h) options? What is the other consequence(s)? The consequence of the software failure incident: The incident described in the article did not result in any direct harm, death, or physical injury to individuals. The main consequences observed were related to delays, inconvenience, and potential risks associated with being stranded due to the software failure. Users were left stranded in remote areas without the ability to start their smart cars, leading to significant delays, frustration, and inconvenience [96445].
Domain transportation (a) The failed system in the incident was related to the transportation industry. The software issue occurred in a smart car rented from Gig, a car-sharing startup, which left the users stranded on the side of a remote highway in California [96445]. The incident highlighted the challenges of relying on technology for transportation services, especially in areas with poor cellular service coverage.

Sources

Back to List