Problems, solutions, benefits

Problem(s) Identified: the complexity, time, effort, cost developing connected car features.

Benefits/solutions provided: technical and business agility by being able to adapt new capabilities into AT’s platform faster, with less repetitive effort by ARD-Tech engineers. Objective - offsetting efforts and costs of DT against potential benefits.

Solutions: end-to-end connected vehicle feature development – e.g. PHEV, ADAS level 2+.

KEY FACTORS CUSTOMER WILL USE TO JUDGE VALUE. (Measurable)

Value drivers: Clarifies which capabilities of this product (as quantified as possible) will be most important to a customers’ perception of its overall value. Can fall into one or more of these categories:

Simplicity – enables AT to experiment and assess new and or friction-reduced solutions, without necessarily having to work through lengthy pre/production processes.

Reduced cost/complexity – reduced time to market, and less in-vehicle validation overhead to bring connected car features or capabilities to market.

Reduced risk – provides ability to demonstrate MVP and gain valuable Customer feedback, before targeting a specific vehicle.

Response to competitors: products to market quicker at reduced cost, with more complete end-to-end product testing – including safety/cyber-security aspects.  

Key technology SDV, digital twin, ANSYS Digital Twin Builder, MBSE.

Specific features Cloud infrastructure, Kubernetes AKS, Capella, Go/Python

CRUCIAL FACTORS AS APPLICABLE. Elements that are not a primary part of the functionality but are key attributes that must be present. May include:

• Security – validate security measures and validate potential attack paths.
• Design/development – support MBSE activities AT to streamline development.
• Viability – assist with establishing a ‘go to market’ decision (notice-of-decision).
• DT to help ensure AT privacy policy upheld.

Phase I activities:      

Details regarding what digital twin technology may provide AT – based on the following aspects:

• Cybersecurity – ongoing TRA, and feasibility of simulating/validating potential attack paths both as-is and with newly developed security measures.
• Sensor adaptation/integration – does DT align itself with AT’s dataflow architecture, and how might it leverage quick uptake of new sensor/actuators?
• Does DT enable validation of vehicle functions to support AT’s ongoing product development and demonstration requirements – i.e., before deploying into a physical vehicle / target platform? Includes: normal daily driving scenarios, edge-cases (harsh weather, crash evasion maneuvers), and faults (failover and recovery mechanisms).

Are there existing, or off-the-shelf digital twin capabilities (including ANSYS DTB) that would enable AT to quickly on-board and deploy real-world vehicle sensors – i.e., without necessarily having to expend dev-time (by ARDUN Tech) integrating them with our solution – outside of connecting the appropriate feed(s)?

• Assist AT inventory those off-the-shelf DT components, and where they may slot into our existing solution.
• Help stand-up and connect DT components into AT’s cloud infrastructure to support our MVP (virtual) slated for 1Q-CY2025.
• What are the pros and cons of this approach vs. e.g., building our own specialized sensor/actuator digital twin solution? Should we investigate other tools or technologies?