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]. |