Shrikant Acharya is the CTO of Excelfore Corporation and Chair of the eSync Alliance. At Excelfore, he drives the company’s technology roadmap and strategic partnerships across the automotive industry. He has led breakthroughs in Ethernet AVB/TSN stacks and smart automotive devices, achieving the first Avnu-certified middleware for endpoints and bridges. At the eSync Alliance, he leads efforts to standardise over-the-air (OTA) data management for connected vehicles, driving collaboration with other standards bodies including ASAM, Autosar, COVESA and SOAFEE.  He previously was co-founder of MARGI Systems (acquired by Harman), helped develop key imaging standards (JPEG, MPEG, JBIG) and held roles at Cirrus Logic and Widergren Communications.

Shrikant completed his undergraduate degree at BITS Pilani and received his MSEE from the University of Texas at Arlington. He holds more than 20 patents

AL Circle: Your website mentions ‘real-world data from all of your vehicles on the road’. What kind of data do you collect from the vehicles that install your software through your deep data aggregation system? And, how do you ensure customer privacy while collecting this data?

Shrikant Acharya: With eDatX (deep data aggregation), the vehicle-side software can collect and normalise program-defined operational data needed for fleet health monitoring and remote diagnostics. The exact signals are customer-configurable, but commonly include:

Software inventory and provenance: ECU/app versions, update history, configuration IDs, cryptographic metadata (e.g., signed manifest identifiers).

Device health and diagnostics: DTCs, watchdog resets, fault counters, resource utilisation, network health, and service status.

Operational telemetry: selected sensor/actuator metrics relevant to the program (e.g., powertrain states, battery/charging KPIs for EVs, thermal states, ADAS subsystem health).

Logs and traces: bounded log excerpts, event timelines, and on-demand captures triggered by faults/anomaly rules (rather than continuous raw dumps).

OTA lifecycle data: download/install success, timing, failures, rollback events, and campaign compliance status.

Customer privacy is protected through a combination of data minimisation and technical/organisational controls:

Purpose limitation and minimisation: Collect only the fields needed for defined use cases (health, diagnostics, compliance). Sampling, filtering, and edge pre-processing reduce volume and sensitivity.

Pseudonymization: vehicle identifiers can be tokenised/hashed; personal identifiers are excluded by design unless explicitly required by the OEM and legally permitted.

Encryption end-to-end: TLS in transit; encryption at rest in the cloud; customer-controlled key management options where applicable.

Access controls and tenant isolation: strict RBAC/least privilege, audit logging, and separation between OEM programs/environments.

Retention and deletion policies: time-bounded retention, configurable by program; support for deletion workflows aligned with privacy regulations.

Regulatory alignment: deployments are typically engineered to meet regional privacy/security obligations (e.g., GDPR/CCPA-equivalent controls) based on the OEM’s program requirements.

AL Circle: What are the safety measures that Excelfore follows while performing a full vehicle OTA update? Are there different update systems for EVs and ICEs?

Shrikant Acharya: Full-vehicle OTA is treated as a safety- and cybersecurity-critical workflow. Excelfore’s eSync OTA is typically integrated with OEM safety processes and standards-driven guidance (e.g., ISO 24089, UNECE R156/R155) and uses multiple layers of protection:

Cryptographic integrity and authenticity: signed metadata and packages, secure key management/PKI, and verification on the vehicle before install.

Policy-based gating: install conditions based on vehicle state (e.g., parked, ignition off, adequate power, network quality), ECU prerequisites, and dependency rules.

Atomic/transactional behaviour: staged installs, sequencing controls, and mechanisms to prevent partial/invalid states across multiple ECUs.

Failsafe and recovery: A/B partitions or equivalent fallback strategies (where supported), rollback/retry policies, and robust interruption handling (power loss, connectivity drops).

Progressive rollout: canary/staged deployment, fleet segmentation, and rapid pause/stop controls if anomalies are detected.

Verification and evidence: post-install validation, health checks, and campaign audit trails for compliance and incident response.

EV vs ICE: The OTA platform is generally the same, but EV programs often introduce additional gating and validation around high-voltage safety, battery state-of-charge constraints, charging sessions, and coordination with BMS/charging/thermal controllers. ICE programs may gate on different powertrain/aftertreatment states. In both cases, the safety model is driven by the OEM’s architecture and safety case, not by the fuel type alone.

AL Circle: How different are the requirements of the clients while developing the SDVconnect framework for different regions across Europe, the US, China, Japan, and India, on major cloud hyperscalers, including AWS, Azure, Google, Baidu, and Tencent platforms?

Shrikant Acharya: Most core SDVconnect requirements are consistent globally (secure OTA, fleet observability, diagnostics, compliance evidence), but regional differences show up in data governance, cybersecurity regulation, and cloud residency/sovereignty expectations:

Europe: strong emphasis on privacy-by-design and data minimisation (GDPR), plus UNECE WP.29 cybersecurity/OTA compliance expectations for many vehicle categories.

United States: privacy obligations vary by state and program; emphasis is often on scalable operations, uptime, and security assurance aligned with OEM internal standards and industry guidance.

China: frequent requirements around data localisation and security assessments, constraints on cross-border data transfer, and use of in-country cloud ecosystems/partners (e.g., Baidu/Tencent) depending on program needs.

Japan: privacy requirements (APPI) and a strong focus on quality/reliability processes; OEM-specific supplier assurance practices can be particularly rigorous.

India: evolving privacy frameworks and strong interest in cost-efficient scaling, connectivity variability, and high-volume fleet analytics; data residency expectations depend on OEM policy and use case.

Across hyperscalers (AWS/Azure/Google/Baidu/Tencent), the application-layer architecture is designed to be portable, while deployments adapt to each cloud’s identity, security services, telemetry pipelines, and regional hosting options. In practice, the largest “delta” is usually not the codebase; it is the compliance posture (data classification, residency, access controls, auditability) and the OEM’s operational model (DevSecOps, incident response, and supplier governance).

AL Circle: Excelfore believes that over just a few years, the Software-Defined Vehicle (SDV) has evolved into what is now known as the AI-Defined Vehicle (AIDV). Why are AIDV potent to represent a major leap forward in intelligence and adaptability?

Shrikant Acharya: SDV makes vehicle behaviour changeable through software; AIDV extends that by using AI models (edge and cloud) to continuously optimise behaviour, detect anomalies, and adapt to context. AIDVs are potent because:

They add perception and inference: AI can interpret complex sensor and system patterns that rule-based logic misses (early fault detection, driver-assist context, energy optimisation).

They enable closed-loop improvement: fleet data trains better models in the cloud, which are then deployed back to vehicles via OTA, improving performance over time.

They support ‘agentic’ workflows: in-vehicle agents can decide what data to upload, trigger diagnostics, or request targeted updates based on detected conditions.

They accelerate personalisation and feature evolution: software + models can tailor behaviour to region, environment, and user preferences within policy limits.

Critically, AIDV also increases the need for governance: model versioning and provenance, safety validation, explainability/monitoring, and secure OTA lifecycle management for both software and AI artefacts. SDVconnect provides the backbone (inventory, data, OTA, audit) needed to manage that lifecycle at fleet scale.

AL Circle: Charging stations can be damaged by weather, accidents, or even vandalism. How does technology protect them from major damage? Can aluminium cast items and other machinery be protected through any software in such situations?

Shrikant Acharya: Technology can’t prevent every physical impact, but it can reduce risk, detect issues early, and limit secondary damage. Common protections for charging infrastructure include:

Ruggedised hardware: weather-rated enclosures, ingress protection (IP) sealing, corrosion control, and surge/lightning protection.

Tamper and intrusion detection: door/open sensors, accelerometers, camera integration, and event logging with alerts.

Remote monitoring and control: continuous health telemetry (temperature, humidity, insulation/ground faults, contactor status), plus remote shutdown/isolation when unsafe conditions are detected.

Predictive maintenance: anomaly detection on electrical/thermal signatures to service units before catastrophic failure.

For aluminium cast items and other industrial machinery, software can similarly enable condition monitoring and protective responses (e.g., detect vibration/impact, abnormal temperatures, moisture ingress, or electrical faults and then trigger safe modes, shut down, or dispatch service). The key is pairing sensors + connectivity + edge/cloud analytics; software mitigates damage progression and downtime, even if it cannot physically “harden” the material.

AL Circle: How true do you think this common notion is — for those who frequently drive 300+ miles (480km) in a single stretch without wanting to plan for charging stops, ICE remains more convenient?

Shrikant Acharya: For many drivers today, that notion is directionally true: liquid refueling is fast and ubiquitous, and it supports long, unplanned single-stretch driving with minimal route constraints.

However, the gap is narrowing. High-range EVs and widespread DC fast-charging make 300+ mile trips increasingly practical, and many drivers naturally take a 15–30 minute break that aligns with charging. Convenience depends on corridor coverage, peak-time charger availability, vehicle efficiency, weather, driving speed, and the driver’s tolerance for planning.

If the priority is “no planning and no stops,” ICE has the upper hand today.

If a short stop is acceptable (and chargers are reliable on that route), EV convenience can be comparable, often with lower operating cost.  However, this is still a developing story.

For fleets, route predictability and depot/home charging can flip the convenience equation in favour of EVs.

AL Circle: Modern vehicles use software-enabled connectivity (V2X, 5G) to communicate with other cars, infrastructure, and the cloud. Is there a difference between ICE and EV when it comes to using such technologies?

Shrikant Acharya: At a technology level, V2X and 5G capabilities are largely agnostic to ICE or EVs. The determining factors are the OEM’s electronic architecture (telematics ECU, gateways, security module), antenna design, and the software stack.

That said, EVs often have additional connectivity-driven use cases—charging discovery/payment, smart charging, battery health analytics, thermal optimisation, and energy services integration—which can increase the value of connectivity and the volume/variety of telemetry.

ICE and EV can use the same V2X/5G standards and security approaches.

EV programs typically emphasise energy/charging-related cloud services and analytics more heavily.

Both require rigorous cybersecurity (certificate management, secure update and communication, intrusion detection, auditability).

AL Circle: How does the shift to a software-defined vehicle (SDV) architecture enable new revenue streams for automakers (both passenger and commercial)?

Shrikant Acharya: SDV architectures turn vehicles into configurable digital platforms. This can enable monetisation over the lifetime of the vehicle rather than only at the point of sale. Common revenue streams include:

Feature-on-demand: paid for performance modes, ADAS features, comfort/infotainment upgrades, or commercial capability packages.

Subscriptions and service tiers: connected services, enhanced navigation, security services, remote diagnostics, and premium fleet dashboard skins.

Data-driven services: predictive maintenance, warranty optimisation, usage-based insurance enablement (where legally permitted), and operational benchmarking.

Commercial uptime solutions: remote diagnostics + proactive parts/service, reduced downtime SLAs, and integration with logistics/dispatch platforms.

Ecosystem and partner revenue: app/service marketplaces, energy/charging partnerships for EVs with charger manufacturers, and revenue-sharing models.

In summary, a reliable OTA can help orchestrate software inventory/provenance, policy rollouts, telemetry data, and audit trails—core SDVconnect capabilities that help OEMs launch and manage such services safely across their fleets.