Building an Open EV Platform for Software-Defined Vehicles
The automotive industry is going through a very disruptive era, just like the smartphone industry back in 2007 when iPhone was first introduced. Internal Combustion Engines (ICE) and gas are becoming irrelevant, replaced by electric motors and batteries. And, more electronic components (ECUs) are introduced into the vehicles. The complexity quickly added up to a point that the whole system became unmanageable. This vertical siloed and distributed vehicle architecture is considered a hardware dump soup, and very hard to be software- defined. Tesla came to the scene and created the first generation of software-defined vehicles. The electrical/electronic architecture (E/EA) became more centralized, called a zonalarchitecture. (Domain v.s. Zonal architecture). E/EA being a more centralized system, the vehicle then can be treated more like a modern computer system with a CPUbrain that controls all hardware components (ECUs). The vehicle’s characteristics (i.e. user experiences) then could be upgraded/updated through Over-The-Air (OTA) software updates. The trend has been urging the industry to move into building Software-Defined Vehicles (SDVs).
Applications with new User Experiences
When vehicles become more software-defined, it opens up huge opportunities for new applications to be introduced and for installed applications to be upgraded. Hence, new user experiences are to be introduced throughout the whole vehiclelifecycle. A new SDV’s user experiences become more like an iPhone with AppStore and many exciting apps to beintroduced and updated throughout the SDV’s life cycle Over-The- Air.
It becomes possible to create a software marketplace for the automotive application space, just like AppStore to the iPhoneor Google Play Store for the Android. The automotive industry immediately become so exciting and the ecosystem with the economies of scale will easily pass the smartphone industry. Imagine one day, Tesla announces Tesla App Store andopens up Tesla EV SDK for all developers to come into the Tesla apps ecosystem to participate in the Tesla applicationsspace. By then, Tesla will be more like the iPhone of EV. For now, Tesla is only the Nokia of EV.
Software 2.0 is eating Software 1.0
Ten years ago, when Marc Andreessen said “Sofware Is Eating The World”, no one had a clue about what Marc was talking about. Today, we all enjoy the apps on our smartphones we carry in our pockets that used to be different hardware gadgets, not software apps.
When Tesla’s AI expert, Andrej Karpathy, said “Software 2.0 is Eating Software 1.0”, he was saying Tesla’s Autopilot software is mostly written by data in Machine Learning (ML) fashion, not by humans in the software 1.0 way. There will be more and more new software 2.0 applications created and some of them will be to replace Software 1.0 applications. Much like AlphaGo Zero is to replace AlphaGo and the traditional software 1.0 game of Go. Aside from that, MLOps is quickly being introduced into replacing some of DevOps.
Therefore, building Software-Defined Vehicles will be following the same trend, it will introduce more Software 2.0 to making more “intelligent/smaret” vehicles. Software 2.0 will be expanding into different domains in automotive industry and related infrastructure from Autonomous Driving(AD)/ADAS to areas like Battery Management Systems (BMS), Driver Monitoring Systems (DMS), Digital Smart Cabins, Thermal Management, Navigations, V2X, Battery Charging Systems, Smart Energy Grid, Storage, and Charging Network, etc.
Open EV Platform (EVKit & SDK)
Tesla is a closed system, much like the first iPhone, introduced by Steve Jobs back on Jan. 09, 2007. iPhone became an open system in applications space more than one year later on July 10, 2008 when Apple introduced iOS SDK and opened up iPhoneAppStore. Apple created an “open” application platform for iPhone and the apps ecosystem grew into today’s mega economic power engine. Android was then created an “open” hardware and software ecosystem that took over the spotlight to become the world’s #1 smartphone platform by volume. Being the world’s first Open EV Platform (EVKit) for Software-Defined Vehicles (SDVs), MIH has grown rapidly since Oct. 16th, 2020, announced during HHTD2020.
EVKit & SDK
EVKit & SDK (software development kit), the Open EV Platform, is for all aspects of the automotive industry, including developers (hardware & software), OEMs & car makers, commercial fleet operators (e.g. robotaxi, commercial fleet), and car owners.
EVKit’s main focus is to create an open platform for software defined vehicles (SDV). To be software defined, a vehicleneeds to have a hardware abstraction layer (HAL) between the hardware platform (ie. rolling chassis or skateboard) and thesoftware platform, so the software layer could ride on top of the HAL and define the whole vehicle as a complete system, a Service-Oriented Architecture (SOA), with software application programming interfaces (APIs). Then future vehicle user experiences (UX) could be defined and created through software applications. The software platform will be compatible to multiples skateboards and the skateboards could be replaced with newer generations. The MIH’s community and ecosystem can continue the innovations assuming the same software platform without rebuilding thewhole vehicle (the traditional approach), hence, it saves a lot of precious investment and the software layer will be evenmore robust and well tested overtime. Further more, if we could move the HAL into the cloud and add hardwaresimulations, future SDVs could be created in the cloud for the most part of the development cycle, hence, digital-twin.
Therefore, car makers (OEMs) could create SDVs in the cloud and put the hardware platform in the loop for final testing and deployment cycles.
The benefits will be:
- Shorten development cycle (saving time and cost)
By introducing the HAL layer, the development cycle could be divided into 2 virtually independent development stacks. Hardware stack, i.e. the skateboard. And, EVKit software stack. Both layers could be developed in parallel, and over time, they will be well-tested, and hence, be more robust. Also, applications rely on the software stack could be continuously updated without effecting the hardware layer, and vice versa. All previous investment could be saved. - Lower entry barriers (creating vibrant ecosystem and new UX)
By introducing the EVKit SDK with robust system architecture and frameworks, experts from different application domains could come and build more innovative future EV applications based on top of these shared system layerand common frameworks, it will lower barriers to entry for all players into automotive industry. At the end, it will create the best in class of all applications to define a vibrant automotive ecosystem. It also expands the economies of scale for the industry.
EVKit’s E/E Architectures
Electrical/Electronic Architecture is the most fundamental of vehicle system where it defines how the whole system work together from the hardware to the software. Historically, automotive industry worked on a mechanical machine where there is limited electrical/electronic components, vehicles behave in a what you see is what you get fashion through mechanical design. Gradually, more and more electrical/ electronic components were introduced to replace the mechanical control system, (e.g. electronic steering/braking, ABS, ASR, ESP, digital cockpit, power windows, powerseats, in-vehicle infotainment system, the engine ECU controls, etc.). Most of the ECUs were added independently without treating the vehicle as a single system, and the whole vehicle were divided into different domains in different silos. Hence, it’s called a domain base E/E Architecture. Most of today’s E/E Architectures are domain base. In this architecture, it becomes too complicated for system management when more ECUs are introduced into the vehicle. A domain base vehicle become a vehicle with many complex systems without a central brain to keep up the whole vehicle as an integrated system to operate efficiently and cohesively.
Tesla began to take the lead for a more centralized E/E Architecture design, called zonal E/E Architecture. It is theindustry’s first attend to design a vehicle more like a modern computer system with the introduction of Ethernet Backbone for data communication, more consolidation of hardware ECUs, and Over-the-air (OTA) software updates to software defined the underneath hardware. Tesla divids the vehicle into physical zones for wiring optimization and abstraction. The result is a big step into wiring saving and more centralized E/E Architecture, and it opened up the exciting possibility and imagination in new user experiences much like the modern PC and smartphone industries.
EVKit’s E/E Architecture design trend is pushing technology limit and adopting the state of the art designs for morecentralized architecture. Once the technology move forward and become available in both capability and price, then it willinch more from a centralized redundant system to a fault- tolerant/clustered elastic computing architecture with cloud native enabled digital twin.
EVKit’s Operating System — The SOA runtime and middleware
A modern EV OS needs to be a software-defined enabler and an open SOA (service-oriented architecture). Being trueSOA, EVKit’s runtime and middleware will enable applications to be SoC and OS agnostic, making the best portability toall applications with least hardware and OSes dependency. EVKit partitions the abstraction middleware layer into twodomains: the mission critical domain (deterministics runtime with functional safety features) and non-mission critical domain. The mission critical domain runtime run on a deterministic core that will guarantee all functional safety and real-time requirements. The non-mission critical domain runtime run on a HPC (cluster in the future) that will provide themost elastic computing environment for a Software Defined fashion for all application services. The middleware and runtime are supported by Data Distribution Service (DDS) with built-in Quality of Service (QoS) that expand across both mission critical and non-mission critical domains.
EVKit’s SOA runtime will have at least two layers of APIs:
1. System APIs (public & private) that interfaces to whole vehicle system resources.
2. Apps & Frameworks APIs for applications developers.
In a SOA vehicle, applications make API calls to create applications for new user experiences. New features and updates could be delivered by OTA throughout vehicle lifecycle.
Security By Design — a Zero Trust Architecture
A cloud connected vehicle will be the most dangerous personal Internet device that a person could have with powerful computation core, huge battery for energy storage and the most functional safety requirements needed for operation at alltime. So, a Zero Trust Achitecture is needed and by design from the group up. Zero Trust is a system strategy for access and communication between two identity points for any given transactions. Before any transaction can begin, the system will go through identity authentication and apply the dynamic policy for authorization. And all transactions are end-to-endencrypted. To enable Zero Trust, a trusted Identity infrastructure or framework need to be established. EVKit chooses adecentralized universal identity approach to build the identity system from blockchain technology and use decentralizedconsensus for the root of trust (the most robust consensus).
Digital Twin — a Cloud Native CI/CD
Automotive Industry is now new to the cloud native approach for a connected vehicle development cycle. The agilemethodology such as CI/CD (Continuous integration and continuous delivery) needs to be adopted. Also, due to manysoftware 2.0 applications has been introduced into EV, besides DevOps, MLOps will be a must in the vehicle development,integration and deployment lifecycle.
Data Model and Identity — GDPR & Data-owner-in-the-loop
EVKit has the GDPR ready data model with the Data-Owner-in-the-loop strategy. EVKit introduces a trusted Identitysystem, it enforces all data access (data’s creation, reading, modification and deletion) to put Data- Owner-in-the-loop to fundamentally taking care of data protection and data privacy issues. The philosophy is to recommend data services to bedivided into three main groups.
1. Data Hosting Services — the parties who hosts all user data.
2. Data Ownership Services — the parties who manage user identity.
3. Data Value Creation Services — the parties who create additional values from data by applying data intelligence (MLor data science)
It is recommended that these 3 parties need to be operated separately and independently. And, always put data-owner-in-the-loop when accessing data.
AD/ADAS — the First Killer App
Today, there will be 1 person killed in a traffic accident for every 25 seconds. A relatively safe AD/ADAS deployed into mobility and some common regulation for using AD/ADAS will be a huge benefit. EVKit’s AD/ADAS architecture is torelease standard DBW APIs (drive by wire) and Sensor Fusion APIs into the mission-critical domain. AD/ADAS domainexperts could use their state of the art technologies for building the best AD/ADAS applications to be installed into MIH’s vehicles. Hence, AD/ADAS can be push into applications layer to support different personalized and levels of Autonomy.
How do autonomous vehicles work?
Autonomous vehicles rely on sensors, actuators, complex algorithms, AI, and powerful processors to execute software. Autonomous vehicles may create and maintain a map of their surroundings based on a variety of sensors in different location of the vehicle. Radar sensors monitor the position of nearby vehicles. Video cameras detect traffic lights, road signs, track vehicles, and detect pedestrians. Lidar (Light Detection And Ranging) sensors use laser scan to measure distances and detect road edges. Ultrasonic sensors are often used to detect curbs and other vehicles when parking. Sophisticated software then processes all those sensory inputs, plots a path, and sends instructions to actuate the car, which control acceleration, deceleration, braking, and steering. Planning policy, obstacle avoidance algorithms, predictivemodeling, and AI object recognition help the software follow traffic rules and navigate obstacles.
AD/ADAS in open platform?
To allow different AD/ADAS developers to access system resources like sensors and chassis from different vendors, it’scritical to standardize the interface.
- Sensor interface APIs : Camera, Radar, Lidar, GNSS, IMU, Infared, HD Map…
- Drive-by-Wire(DBW) APIs : Longitude and Latitude control
With standard sensor and DBW interface, it will be easy for the car to be sensor and chassis agnostic. So, car makers caneasily change sensor and chassis vendors. The drivers can change AD/ADAS vendors to make better user experiences. The component suppliers can have the opportunity to enter vehicle supply chain if the product conforms to the standard. Thedevelopers can also focus on developing creative applications without having to worry the hardware characteristic from different vendors. With this open approach, it can speed up the development process and lower the entry barrier for the ecosystem.
To bulid a smart vehicle or smart infrastructure?
For the scalability of AD/ADAS, we believe that it is better to build a smarter vehicle first than to build a smartinfrastructure. To scale up smart infrastructure is much more expansive and time consuming, hence it is less scalable.Vision base AD/ADAS application using AI/ML model is the major disruption in making a smart vehicle that could driveitself very cheap. Once the standard DBW APIs and Sensor fusion APIs are open, we believe EVKit could drive the AD/ADAS innovations and provide the market place the best value with scale.
Smart City Adaptor Layer for smart infrastructure
For a world smart EV to be deploy to different countries and regions, it can’t require all other smart infrastructure layersto be built uniformly, otherwise, the smart EV localization in smart cities won’t be able to be scaled up globally. But incase of local smart city rules and regulations with V2X integrations, EVKit’s SOA and APIs base standard makes it easy to have a portable adaptor layer APIs for different smart city integrations and requirements. When the vehicle ready to be deployed, it only need to replace with the local smart city adaptor layer without changing any other vehicle domain specific applications or even the core system. The EV localization to smart city will be portable and flexible.
MIH Working Groups
MIH’s technical committee oversee currently many Working Groups (WGs). The working group is to discuss and proposestandard APIs for the specific expert domain. Currently, there are 18 WGs in all different domains to recommend thestandards and APIs.
Conclusion
There are many more specific areas to be discussed that hasn’t been covered such as carbon neutral, energy grid, openBMS and Adaptive Vehicle Dynamics etc. in building a software-defined, extremely intelligent mobility future. An openEV platform like “Android of EV” should be a great way to start, and eventually to achieve our goal in accelerating the distruption of the automotive industry.
