Tesla Cybertruck Catches Fire From Crash Into Fire Hydrant

Touching water continues to be a problem for Tesla engineering, as in this case it apparently caused their ill-conceived vehicle to burst into toxic flames.

The crash took place at 4:45 p.m. between Sam’s Club and Bass Pro Shop, off of Spur 54 and Bass Pro Drive, when a Cybertruck crashed into a fire hydrant. Assistant Fire Chief Ruben Balboa with the Harlingen Police Department said the Cybertruck’s battery ignited after the water from the fire hydrant soaked it.

Read that again. When a Cybertruck crashed into a fire hydrant and was soaked with water, it ignited into a fire.

NJ Tesla Kills One in “Veered” Crash Into Tree

So many Tesla crash into a tree in the early morning hours, it’s getting hard to tell them apart.

The fatal NJ crash reported August 18th is not to be confused with this one reported August 20th.

Haas was the passenger in a Tesla Model Y that left northbound Lanwin Boulevard last Tuesday, Aug. 20, at about 3:45 a.m. West Windsor police said in a statement that patrol officers arrived to find the car crashed into a tree near Providence Drive, in a residential neighborhood, and the passenger side suffered major intrusion damage.

Fatal Tesla Cybertruck Wreckage Reveals Dangerous Design Defects

Experts reviewing the IAAI auction page say the Cybertruck wreckage looks like a vehicle built in the 1960s.

Fifty years of standard safety design improvements are missing, meaning it’s safer to drive any other vehicle made after the 1960s than the Cybertruck (even a Pinto).

Police haven’t revealed much, but a leading theory is that the driver was trying to test the “survivability” promises of Elon Musk. Driving off-road near Houston they died almost instantly after crashing in the first ditch.

Related: the official Tesla first responder page for at least ten months has not had any information at all on the Cybertruck.

Also related, here are the far too many other Cybertruck wrecks currently up for auction.

Solid and V2X: Addressing Cybersecurity Concerns in U.S. DoT National Deployment Plan

Right in the middle of the fresh new announcement of the U.S. vehicle to everything (V2X) deployment plan, is the following brief section on security concerns.

Secure Deployment: Cybersecurity and Privacy Principles Successful V2X deployment requires cyber resilience so its communication services remain available and all users have confidence in the integrity of V2X data as well as trust in the confidentiality of data exchanged via V2X communications. This requires applying principles of secure by design — considering cyber and privacy risks at the outset and integrating cybersecurity principles when V2X is developed and deployed. Secure and resilient V2X depends on investment in cybersecurity and adopting a comprehensive approach to manage and reduce cyber risk.

Cybersecurity is critical to ensure V2X technologies — and the information they provide — can be used and are trusted through standard procedures to validate that information is correct. Secure V2X deployment includes ensuring Personally Identifiable Information (PII) is protected while also allowing parties to secure the data needed to advance a safe and efficient transportation system. Privacy of individuals must be considered and the collection and use of PII and potential PII must align to the purpose of the program. Participants must be informed of privacy practices and provided with understandable notice and provided options for consent. PII collected should be the minimum necessary for the purpose for which it is collected, maintained for the shortest time practical, and not used for any other reason than for which it was initially collected.

The DOT is cognizant that realizing secure V2X deployment requires implementing cybersecurity and privacy principles in a clear and practical way. The ITS Cybersecurity Research Program website documents DOT and modal agencies’ resources. The DOT commits to developing and maintaining cybersecurity resources for the V2X community, as well as a detailed and testable definition of secure V2X deployment in support of this Plan.

Here’s a related presentation about $238M, earmarked for vehicle safety innovation and “foundational” cybersecurity, as described by Federal Highway Administration’s Shailen Bhatt:

The Department of Transportation (DOT) highlights the critical need for cyber resilience, data integrity, and user trust in V2X systems. At first glance, the W3C Solid architecture (solidproject.org) appears to align well with these objectives and offer enhancements. Solid’s decentralized approach to data storage—distributing it across a network of vehicles—and its emphasis on user control over personal information inherently reduce attack surfaces and limit the impact of potential breaches.

A DOT concern clearly is the protection of PII while facilitating essential data sharing to save lives. Solid addresses this balance better than most by allowing users to store data in personal data wallets, which only disclose specific information when and where necessary. This approach adheres to the principle of data minimization for maximum benefit, as V2X applications can request only the data required for their functions. Solid’s permission system ensures that data is used strictly for its intended purpose, as specified during the consent process.

Furthermore, the DOT emphasizes the importance of transparent privacy practices. Solid’s standardized consent mechanisms facilitate clear protocols for data access requests and permissions. Users have the ability to easily view and manage which applications can access their data.

Additionally, Solid’s interoperability aligns well with V2X requirements, enabling seamless data exchange between various systems and stakeholders. This ensures scalability as V2X adoption grows and supports a diverse network of transit vehicles. By enhancing user control over data while meeting data protection requirements, Solid helps build public trust and supports advancements in V2X technologies.

Considering these benefits, V2X-specific extensions to the Solid protocol could be a promising next step. Solid-compatible applications might start with small-scale deployments to validate these advantages (unless Bhatt is serious that he wants to start deploying immediately at scale). The following code example illustrates how vehicles could use Solid to securely share personally controlled location data with nearby vehicles:

import { SolidDataset, Thing, createSolidDataset, setThing } from '@inrupt/solid-client';
import { fetch } from '@inrupt/solid-client-authn-node';
import jwt from 'jsonwebtoken';
import { v4 as uuidv4 } from 'uuid';
import crypto from 'crypto';

// Generate DPoP proof for secure requests
const generateDpopProof = (url, method, privateKey, accessToken = null) => {
  const payload = {
    htu: url,
    htm: method,
    jti: uuidv4(),
    iat: Math.floor(Date.now() / 1000),
    ...(accessToken && { ath: crypto.createHash('sha256').update(accessToken).digest('base64url') })
  };
  return jwt.sign(payload, privateKey, { algorithm: 'ES256', expiresIn: '5m' });
};

// Retrieve access token from token endpoint
const getAccessToken = async (privateKey) => {
  const tokenEndpoint = 'https://oidc-provider.example.com/token';
  const dpopProof = generateDpopProof(tokenEndpoint, 'POST', privateKey);
  const response = await fetch(tokenEndpoint, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/x-www-form-urlencoded',
      'DPoP': dpopProof
    },
    body: new URLSearchParams({
      grant_type: 'client_credentials',
      client_id: process.env.CLIENT_ID,
      client_secret: process.env.CLIENT_SECRET
    })
  });

  if (!response.ok) throw new Error('Token request failed');
  const { access_token } = await response.json();
  return access_token;
};

// Share vehicle location with a recipient URL
const shareVehicleLocation = async (vehicleId, { latitude, longitude }, recipientVehicleUrl) => {
  if (latitude < -90 || latitude > 90 || longitude < -180 || longitude > 180) {
    throw new Error('Invalid coordinates');
  }

  const privateKey = process.env.PRIVATE_KEY;
  const accessToken = await getAccessToken(privateKey);
  const url = `${recipientVehicleUrl}/vehicleLocations/${vehicleId}`;
  const dpopProof = generateDpopProof(url, 'PUT', privateKey, accessToken);

  const thing = new Thing(`vehicle-${vehicleId}`)
    .addLiteral('https://schema.org/latitude', latitude)
    .addLiteral('https://schema.org/longitude', longitude)
    .addDateTime('https://schema.org/timestamp', new Date().toISOString());

  const dataset = setThing(createSolidDataset(), thing);

  const response = await fetch(url, {
    method: 'PUT',
    headers: {
      'Content-Type': 'application/ld+json',
      'Authorization': `DPoP ${accessToken}`,
      'DPoP': dpopProof
    },
    body: JSON.stringify(dataset)
  });

  if (!response.ok) throw new Error('Failed to share location');
  console.log('Location shared successfully.');
};

// Example usage
shareVehicleLocation('V123456', { latitude: 37.7749, longitude: -122.4194 }, 'https://example-vehicle.pod')
  .catch(error => console.error(`Error: ${error.message}`));

Yes, latitude 38 because… go Giants!

The code takes a key aspect of V2X communication, where vehicles can share location data to improve safety and traffic management, and adds a Solid data wallet to store and control access to location information without needing to operate a centralized database. DPoP tokens are shown to prevent unauthorized access and ensure data integrity

Some potential Solid extensions for V2X include specialized ontologies, efficient geospatial queries, and real-time data exchange mechanisms.

Here’s an Intersection OWL Ontology to define some basic classes and properties relevant to V2X interactions, such as vehicles, traffic signals, and signal phases:

@prefix v2x:  .
@prefix schema:  .
@prefix xsd:  .
@prefix owl:  .
@prefix rdfs:  .

# Define the Vehicle class
v2x:Vehicle a owl:Class ;
  rdfs:subClassOf schema:Vehicle .

# Define the hasSpeed property
v2x:hasSpeed a owl:DatatypeProperty ;
  rdfs:domain v2x:Vehicle ;
  rdfs:range xsd:decimal .

# Define the hasDirection property
v2x:hasDirection a owl:DatatypeProperty ;
  rdfs:domain v2x:Vehicle ;
  rdfs:range xsd:decimal .

# Define the TrafficSignal class
v2x:TrafficSignal a owl:Class .

# Define the hasPhase property
v2x:hasPhase a owl:ObjectProperty ;
  rdfs:domain v2x:TrafficSignal ;
  rdfs:range v2x:SignalPhase .

# Define the SignalPhase class with specific instances
v2x:SignalPhase a owl:Class ;
  owl:oneOf (v2x:Red v2x:Yellow v2x:Green) .

# Define the specific signal phases
v2x:Red a v2x:SignalPhase .
v2x:Yellow a v2x:SignalPhase .
v2x:Green a v2x:SignalPhase .

And here’s a Query to a geospatial index to report nearby vehicle status. This example assumes the use of a hypothetical Solid extension for handling geospatial data:

import { SolidGeospatialIndex } from 'hypothetical-solid-v2x-extension';

const cityIndex = new SolidGeospatialIndex('https://city-traffic.example/index');

async function getNearbyVehicles(lat, lon, radius) {
  const query = `
    PREFIX geo: 
    PREFIX geof: 
    SELECT ?vehicle ?lat ?lon
    WHERE {
      ?vehicle geo:lat ?lat ;
               geo:long ?lon .
      FILTER(geof:distance(?lat, ?lon, ${lat}, ${lon}) <= ${radius})
    }
  `;
  
  return cityIndex.query(query);
}

const nearbyVehicles = await getNearbyVehicles(40.7128, -74.0060, 1000);
console.log(nearbyVehicles);