Architecture

Cloud to Vehicle Architectural Elements

On-Vehicle Architecture
Exposing More Capabilities and Standardization

jmiloser@ford.com
Cloud / Vehicle Architectural
Elements
 Overview

Smartphone App
• Remote Features
• Localizations
• Dealer-specific request

FORD Backend Systems

3rd Party Contents
• Traffic, Weather
Enterprise • B2B Services
• B2C Services
• Mapping, Routes Cloud • Dealer Management system

Infrastructure
AZURE CLOUD

• Embedded modem is regarded as key

enabler for connected vehicle eco system.

• Modem uses the vehicle capabilities to

deliver a wide bandwidth of advanced
telematics features.
Vehicles with
Embedded Modem
3
FNV-Vehicle/Cloud Messaging Pattern
FCI and Ford cloud uses bi-directional messaging based on one of the following messaging pattern.
• Command & Response: Ford cloud uses this pattern to issue commands to vehicles, with vehicle sending
response back to cloud. Each command response is correlated and uses a correlation ID issued by the Ford Cloud.
• Command/Response & Alert: The ECG follows a unique message model to publish the Alerts (correlated alerts)
by correlating the SDN commands. The SDN correlates the Commands, Command Responses and Alerts with a
MessageID and CorrelationID.
• Alerts(Unsolicited Messages): Vehicle follows a one-way message exchange model to publish vehicle generated
Alerts (non-correlated alerts) to the SDN; the SDN processes the message without correlation of command
messages.
• Query & Response: Message model used by vehicle to generate queries(request) to cloud and get response back
from cloud. Response to query is correlated and tracked using the correlation ID issued by vehicle.
• Composite Pattern: Unique message pattern where vehicle queries the cloud to check for new updates, get a
response back from cloud and then cloud caches the correlation id to issue a update command back to vehicle and
wait for response. Initial transaction is initiated by vehicle followed by a correlated command from Ford cloud.

source https://www.eesewiki.ford.com/pages/viewpage.action?pageId=8024822#FNV2FordCloudInterfaceArchitecture(FNV2-FCI)-Interfaces 4
 FNV2- Vehicle 2 Cloud Architecture
Fully Networked Vehicle uses FCI and SOA Middleware, ECG SW components to exchange vehicle and
cloud data between Ford Cloud and vehicles.

Ford Cloud Interface (FCI) - Ford Cloud Interface is the ECG gateway to the Ford SDN and Azure. Implements FTCP protocol.
Software Updates Manager (SWUM) - The component that is part of ECG responsible for vehicle software updates.

source: https://www.eesewiki.ford.com/pages/viewpage.action?pageId=8024822#FNV2FordCloudInterfaceArchitecture(FNV2-FCI)-Interfaces
5
 Use Case – Enhance Script Engine for Data Analytics
Summary of Change: Update FTCP to support Script Engine's generic commands and script management commands.
Feature Owner: Stephen D'Souza, Abey George, Murali Chitturi
Model Year: MY21
Feature Type: New Feature
Reason for Change:
1. To manage the lifecycle of installed script applications (start/stop etc.) from the cloud, new script management commands is being added.
2. In order for script applications to support data formats that are not predefined, a generic flexible format is being added.
Specific Document(s) Impacted: New proto file scriptengineFTCP.proto to be added
Nature of the Change: New commands, responses and alerts
Constraints: ECG, Cloud
Dependencies: FTCP, ECG, Cloud

“Lua scripts are intended to be used for data collection. We need the ability to start and stop them from the cloud.”

source: https://www.eesewiki.ford.com/display/ecg/ECG-CLD-SCRIPT++Script+Engine+Architecture 6
 Use Case - Script Engine

• Provides a framework for executing LUA based script applications on the ECG.
• Script Engine runs its managed scripts in a 'sandboxed' environment with a subset of the LUA APIs and
constructs.
• Uses a single SOA client which is shared between all scripts. The script’s descriptor controls access to
Services.

FNV2 Ford Cloud Interface

ScriptSDN
Application 1 TCU
(FNV2-FCI)
• LUA Adapter Interfaces Cellular or WiFi or
• ftcpPublishAlert AppLink
FNV2-SOA-FCI-IF
Connection
• ftcpPublish Response
ECG App Services
• soaSubscribeToData
FNV2- SOA Middleware
TCU
Script Application 1

SYNC

source: https://www.eesewiki.ford.com/display/ecg/ECG-CLD-SCRIPT++Script+Engine+Architecture
https://www.lua.org/about.html 7
Use Case - Script Engine
Ford Cloud
Interface(FNV2-FCI)
FTCP
.proto

source: https://www.eesewiki.ford.com/display/ecg/ECG-CLD-SCRIPT++Script+Engine+Architecture 8
FTCP, GPB

Ford Telematics Communication Protocol (FTCP) is designed to provide communication between Vehicle (ECG) and Cloud Infrastructure. FTCP uses MQTT
(Message Queue Telemetry Transport) protocol for message communication leveraging TCP protocol. The payload, sent from the Vehicle (ECG) to Cloud and
vice-versa, is defined using Google Protocol Buffers (GPB) to take advantage of the name-value pair model for creating data structures.

MQTT is an extremely lightweight publish/subscribe open source messaging transport. MQTT 3.1.1 is an approved OASIS standard for machine-to-machine
(M2M) connectivity protocol.

FTCP follows MQTT specification version 3.1. For more information about MQTT, please visit http://www.mqtt.org
Google Protocol Buffers (GPB) is a language-neutral, platform-neutral extensible way of serializing data structures to define payloads for communications
protocols, data storage…etc. GPB is efficient, flexible and automated mechanism for serializing structured data. It also offers flexibility to change data
structure without affecting already deployed programs.

FTCP Ford Cloud

GPB, .proto Interface(FNV2-FCI)

source: Ford Telematics Communication Protocol Specification 6.0.9 9

Use Case - Script Engine (.proto)

Compilers
C++
ECG
C
TCU,
ADAS,
AUTOSAR

protoc -I=scriptenginesource --cpp_out=scriptenginedest scriptenginesource/ScriptEngine.proto

source: FTCP_6.0.9/ScriptEngine.proto 10
 Curious to learn more
Step 1 – Install Broker (Server) Step 2 – Install Client
https://mosquitto.org/ https://projects.eclipse.org/projects/iot.paho/downloads
The MQTT protocol provides a lightweight method of carrying out messaging using The Eclipse Paho project provides reliable open-source implementations of
a publish/subscribe model. This makes it suitable for Internet of Things messaging open and standard messaging protocols aimed at new, existing, and emerging
such as with low power sensors or mobile devices such as phones, embedded applications for Machine-to-Machine (M2M) and Internet of Things (IoT).
computers or microcontrollers.

Step 3 – Protocol Buffers Step 4 – Try some messaging patterns

https://developers.google.com/protocol-buffers/docs/tutorials
• Request/Response
• download compiler • Broadcast
• define payload in .proto file • On-Demand Broadcast
• compile .proto file
• create topic A MQTT topic is a UTF-8 string which is used by the MQTT broker to
• publish/subscribe to topic using generated code filter messages for each connected client. Consists of one or more topic
levels. Topics can be considered as SOA endpoints.

source https://www.eesewiki.ford.com/display/ecg/FNV2-SOA%3A+MQTT+Topic+and+Message+Structure 11
Summary
 Use Case - Enhancement to Script engine flow for Data Analytics
 .proto file structure, GPB
 FTCP
 FCI
 Script Engine
 SOA Middleware, Service Manager
 Messaging Patterns

On-Vehicle Architecture

Ford Cloud
Interface(FNV2-FCI)
FTCP
.proto

12
Vehicle Architecture
FNV2 - Vehicle Architecture
Fully Networked Vehicle introduces the Enhanced Central Gateway (ECG) with following goals:
• Access to meaningful information from all the connected ECU's and to
• Enforce security policies to ensure that appropriately authorized access to these ECU's is permitted.
• Replacement of vehicle’s Smart Data Link Connector
(SDLC), adding support for Ethernet connectivity and
computing resources to implement security controls and
information management.

source: www.eesewiki.ford.com/display/ecg/ECG+Software+Architecture+Overview
14
FNV2– SOA Middleware
ECG introduces an industry proven Service Oriented
Architecture framework to build API driven layered architecture
within vehicles. ECG introduces a SOA middleware software
component to provide following services:
• Service Registration/discovery: This block allows each service connected to the
framework to register so they can be discovered by clients. This is where dynamic
metadata of services such as policies or QoS are stored as well as service life cycle status
(stopped, listening, etc.).
• Encryption: For remote clients located outside of the ECG, TLS encryption is
recommended. This library includes the main cryptographic algorithms and other facilities
(e.g. OpenSSL).
• Authentication & authorization: For local clients, there is no encryption required and a
simple authentication mechanism is sufficient based on uid/gid or username/password.
Once a client is authorized to connect, the SOA checks if the client is authorized to access
the requested services.
• Queue: It may be required to queue some of the messages if a client is not connected, so
once it connects, the relevant messages can be delivered.
• Routing: This block includes the mechanism required to direct messages between the
client and the service, including filters.
• Transaction logger & Telemetry: Various events need to be reported as connected
clients, permission denial, etc.

source https://www.eesewiki.ford.com/pages/viewpage.action?pageId=99815030
15
 What is Service Oriented Architecture (SOA) @ Ford
Data
• SOA offers consistent access to data source variation. User Press_LF

• SOA is for non-time critical data communication. “consumer”

• A style of software design, bringing in the concept of Services Data

Press_RF
• Services provide a cohesive set of data in the form of information. Service
• Data can be disperse or calculated (number of tire rotations) Tire Info
Data
Rotations

• Information contained in the Service can widen/narrow without breaking the essence of
the Service.
• Application Programming Interfaces (APIs) are the key to accessing and providing
Service information.
• The collection of these APIs form a broad Vehicle level API driving innovation

16
 What is Service Oriented Architecture (SOA) @ Ford
• Define and publish on-vehicle Services that encapsulate vehicle capabilities
• Enable FNV strategy by specifying contracts aligned with generated APIs
• Provide access and actuator control aligned with Service Oriented Architecture
(SOA).
• Management, process, workflow and tooling of Services versions and
traceability.

• How do you interact with a service?

• multiple features can access one or more services
• multiple client subscriptions
• request information
• request change of hardware device’s state
• build conditional business logic from richer information

Challenge today -
Some data already exists in our CAN database but needs transformation to support SOA.
Some data is only available using Diagnostic commands but does not provide a generic interface.
Some data resides in private Supplier DIDs or not exposed at all.

17
Guidelines for a Service
1. Loosely Coupled Service contracts are designed to be as independent of the service implementation as
possible, minimizing the need for service contract changes if the implementation changes.
Also service level abstraction should decouple implementation details.
2. Highly Cohesive The degree to which the elements of a certain module belong together. Grouped by a single
well-defined task of the module. e.g. (door functions)
3. Resilient Services should be able to provide and maintain an acceptable level of service in the face of
faults and challenges to normal operation.
4. Stable Interactions should be consistent across vehicle variations.
5. Atomic* Services provides a business function that is independent of other services.
6. Reusable & Provides information at a level that is meaningful to many potential consumers for various
Relevant purposes, retaining a consumer/customer focus. Depending on their granularity, services
should be usable by multiple processes and other coarse-grained services.
7. Contract Based Interface and policies are strictly described by an interface specification.
8. Platform- Both the consuming and SOA service systems can be on any platform that supports the
independent service transport and interface requirements.
9. Backward Services must be backward compatible. The service provider must extend or add rather
Compatible than change.

*two types of services are provided to enable different vehicle level software architectures

source: http://wiki.ford.com/pages/viewpage.action?spaceKey=CS&title=Service+Guidelines+Info 18
 FNV3 Objectives
 Utilize FNV2 Platform Capabilities more fully.
 Increased use of common platforms - AUTOSAR.
 Prepare for next generation of customers and partners.
 Enable the migration of more in-house software development.
 Prepare the software for physical architectural changes: compute clusters, smart sensors/actuators.
 Enable faster integration of new technologies.

FNV3 Utilization
• group vehicle capabilities 32 Services Slight Reduction, Enhanced for
More ECUs, More Scale from Sync
• provide to application layer Service Use Connectivity Use
(22 Body Domain) data to more systems
• provide for features Increase Cases

Platform Capabilities
SOA Script FNV
• leverage existing
VIM PARSED
• enhance for future Framework Engine Analytics

19
 Vehicle Architecture with SOA Layers
Presentation Layer
• User interaction layer SYNC HMI Ford Pass APP Third Party App Voice Commands Switches, buttons
• Potential Consumers for features
Communication
Framework
Apps/Features
• Implement domain agnostic business Zone
Control My Phone As A EV Smart Pause and
logic Lighting …Features
Car Feature Key Charging Resume
• Decouple feature from IO Feature
• Does not handle Time Critical, functional
safety and regulatory requirements Communication
Framework
Vehicle Services
• Vehicle Network Agnostic Door Windows Alarm Battery Camera Light
…Services
• Decouple feature from IO devices Service Service Service Service Service Service
• Perform feature arbitration, request and
response queue management
Communication
Framework

Commodity ECUs
• Handle time critical functionality. Functional
Time
Service Final IO Safety and Legacy
• Maintain legacy features Critical
Handler(s) Arbitration Regulatory Features
Functions Functions
• Perform final arbitration, hardware
protection, regulatory requirements,
functional safety, etc. Body Domain
• Implements Service Handlers to expose
input/output signals to vehicle services. Powertrain Domain
Chassis Domain
ADAS Domain

20
SOA Security Architecture

• Access Control List (ACL) – database where permissions are managed by the
Service Manager, whitelist strategy
• SOA Gateway – single TLS session, access to certificates and keys required to
establish a secure connection to the ECG
source https://www.eesewiki.ford.com/pages/viewpage.action?pageId=8026191 21
Software Architecture Pattern

22
 AUTOSAR ECUs on Ethernet

• Complex Device Driver (CDD) – mechanism to allow enhancements and customizations; used for adding MQTT capability.
• SOA Gateway CDD – version created to enable AUTOSAR ECUs connectivity to the SOA framework
• Service Handler – Software Component(SWC) used for data transformation, message processing, connection to application logic

sources: VDOC07864–AUTOSAR SOW, VDOC077709-FNV3 Planned Scope, https://www.autosar.org/ 23

 Service Handler Types
Ford teams

 AUTOSAR Conversion
Functional
Service
Handler(s) Final IO Time Safety and Legacy  Service Handler Implementations
Critical
Arbitration Regulatory Features  Model Updates
“Alarms” Functions Functions

Body Domain (BCM)

…Services
Tier1s
Ford teams
Service Functional
 Specifications Handler(s) Final IO
Time
Critical
Safety and Legacy
Arbitration Regulatory Features
 CAN message/signals (new/modified) “Doors” Functions
Functions
 Functional Specs updates
Body Domain (Body Ancillary Modules)

24
Typical Service Structure
• Priority: Body domain & Camera
• Uses FNV components
• Provided, Required Contracts
• .proto file

New Feature Service Feature SPSS with

Specification Specification Service Contracts

2019 – gathered capabilities of vehicle from SMEs, Functional Specs.

With current and future FNV platform capabilities in mind, defined Services
and related Contracts, published .proto files.

2020 – transitioning current and future features to utilize Services. Analyzing

sets of features for possible new or enhanced Services.
25
Camera Architecture

• Physical Camera has Camera Service

• Camera Manager Service
• Camera Service, Camera Manager Service

sources http://wiki.ford.com/display/CS/Camera+Video+Streaming

26
Camera Service

sources http://wiki.ford.com/display/CS/CameraService
27
https://github.ford.com/sw-architecture/idl/blob/master/CameraService/CameraService_Provider.proto
Camera Manager Service

sources http://wiki.ford.com/display/CS/CameraManager+Service
https://github.ford.com/sw-architecture/idl/blob/master/camera-mgr-srvc/CameraManagerService.proto
28
Use Case – Enhanced Dash Camera (EDC)

29
Use Case – Mobile Device Viewer (MDV)

30
Entering Design Phase

FNV3

sources https://www.eesewiki.ford.com/display/fnv/FNV+System+and+Software+Architecture#
http://wiki.ford.com/display/CS/Camera+Video+Streaming
31
Entering Design Phase

Vehicle Control Services

source https://www.eesewiki.ford.com/display/ecg/ECG+Software+Architecture+Overview#ECGSoftwareArchitectureOverview-FNV2VehicleServices 32
ECUs Not On Ethernet (AUTOSAR/NON-AUTOSAR)
ECU Team’s Architecture and Design Decisions
 Is an adapter needed?
 Can an existing arbitrator be used? Should it
be enhanced?
 Is an arbitration layer needed?
PARSED
Server
 Are new CAN messages/signals needed?

OVTP

• Vehicle Information Manager (VIM)

• Processing and Reporting System for Efficient Data (PARSED) Server
• On Vehicle Telematics Protocol (OVTP)
• Body Ancillary Modules (BAM)

33
PARSED and FNV Analytics
• PARSED and FNV Analytics covered in other training.
• Services have access to FNV2 SOA Middleware
• Can leverage PARSED data and Analytic data.
• Not a replacement but provides additional design options.
• Provide safe and consistent control of devices.

PARSED Client FNV Analytics

https://www.eesewiki.ford.com/display/ecg/ECG+PARSED+Controller+%28ECG-PARSED%29+HLD
sources
https://www.eesewiki.ford.com/display/analytics/FNV2+Analytics+System+Design+HLD+1.1 34
Window Analysis – Control Module (CAN)
Service Contract Request* Response*
(realized on ECG)
Message Description Detailed Meaning Message Description Detailed Meaning

PassRrWindowMovementRqst Request PassRrWindowMovementRsp Response

NULL NULL
OPEN SUCCESS
CLOSE PENDING
MOVE_ABSOLUTE_POS REJECTED
CANCEL INTERRUPTED
DELETE FAILED
INVALID IN_PROG
RESERVED... FAULT
RESERVED...
PassRrWindowMovementRqstID TRANSACTION_ID
PassRrWindowMovementArb Arbitration
PassRrWindowMovementType Type
NULL
IMMEDIATE LOCAL
WAIT SOA
PDB
PassRrWindowMovementSource Type
PassRrWindowMvRspID TRANSACTION_ID
ONBOARD
OFFBOARD PassRrWindowAbsPosRsp Data

Authentication Strategy CMA, Counter, CRC, ... Authentication Strategy CMA, Counter, CRC, ...

*not approved by Netcom

Vehicle Information
Manager
(FNV2-VIM) 35
 F – Feature
Functional Architecture Role and Deliverables S - Service
f - function
Work with stakeholders to determine near and far term solutions
Perform Feature optimization
Create an end-to-end solution
Top down software architecture driven decisions (schedule HW changes)
Drive appropriate infrastructure changes using a deliverable approach
Hardware, Electrical, Solution Architects

SysML End to End UML Software Architectures

Solution Allocations to ECUs
F3 , f 4 Architecture S2, F2, f5 Services, Contracts
Feature Specifications
{APIs, GPBs, Structure, Behavior}

36
SOA Governance Toolkit

2019 – evaluation of IBM, Siemens PLM&ALM, Software AG, Google, Microsoft

Pilot of Software AG. 2020 internal Ford IT developed solution.

• Web based application

• Ability to create, view, track and edit a Service and Service Contracts through its lifecycle
following a defined workflow.
• Generate files (GPB, JSON, XML)
• Ability to update and track dependencies among Services and service bundles, with
dependencies based on the version.
• Ability to search on all service definition metadata and fields.
• Ability to define and enforce various policies and rules regarding services and contracts
and workflow.
• Ability to integrate with applications such as Jira, GitHub, Polarion, VSEM, and PREEvision
where required.
• Ability to generate and export wide variety of reports/views.
• Ability to limit/restrict actions, views, etc. utilizing role-based accessibility.
• Flexibility to support future integrations and requirements.
• Ability to have workflow event and notifications in the tool for lifecycle events by version.
37
Summary
• FNV2 Vehicle Architecture, SOA Middleware
• FNV3 Objectives
• SOA, Ford’s Strategy
• Services leverage platform components, SOA Gateway Component
• Camera Architecture, new feature use cases
• ECUs with/without Ethernet Connectivity, CAN communication patterns
• Workflow, Feature Owner Support
• Service Management

On-Vehicle Architecture

Ford Cloud
Interface(FNV2-FCI)
FTCP
.proto

More access, more control

38
Standardizing
More Device Control
More Attributes for Collection
 Baseline, Observations, Plan
What do we have now? What can we add?

Harmonize attributes per device type

• Brightness, Color, ON/OFF Status - Lamps
• Average RPM - Motors
• Duty Cycle – Actuators, Pumps, Motors
Lamps Motors Switch Sensor Actuator • Current – All applicable
• Status – All applicable
• …

DIDs DTCs Create Additional DIDs

• Status • Short to Ground • Usage Counters
• Configuration • Short to Battery • Attribute For Command And Control
• Functional failures • Faults • Brightness
• Filtered Values • Color
• Current • Sensor Val
• Voltage • Required RPM
• Configuration
• Warranty Spend – High priority DIDs
• Analytics
• Observations
• All Common Devices do not have same list of DIDs
• All Pressure Sensors do not have same set of DIDs Create Additional DTCs
• Supplier DIDs vary – parts / programs / features • Fault by Sensor
• Depth and meaning of Supplier DIDs varies
• Fault by Motor Operations
• Most Recent faults
• Source of Fault
40
What do we have now? – FNV Program Devices Analysis
COUNT OF DEVICES = 624
100 87

80 65 66
50 55
60 48 44
35
40 21
20
0
Actuator ECU Lamp Misc Module Motor Multi Device Sensor Switch

Count of Read DIDs = 471 Count of Control DIDs = 162 Count of CAN Read Messages Count of CAN Control Messages
87 = 440 = 166
33
29 80
66 37
65 25
50 55 48 19 21 52 52 51 53
47
57
25
44 22
35 13 12 18 19
27 16 14
21 21
6 4 8 7

41
 GMRDB Analysis – For Existing DIDs Across Programs
Body Body Hybrid Vehicle To Be
Powertrain Electrical Chassis Grand Total
Exterior Interior Technology Personalization Analyzed

Actuator 340 24 106 64 61 16 8 619

Lamp 136 66 4 206
Motor 8 19 3 46 3 67 146
Sensor 207 117 23 568 915
Switches 95 1 85 181
Grand Total 555 179 318 67 196 19 1 732 2067

• GMRDB_withComments_20200205_070812
• Existing DIDs : 5279
• Mapping
• DID to Device Type
• 2067 Done
• 3212 Pending
• DID to PMT (based on 2067 DIDs)
• 1335 Done
• 732 Pending

• Work Is still in Progress…

42
GMRDB Analysis – Projections for Additional DIDs
Existing DIDs Vs Projected DIDs
Categorized per Device Type per PMT
1000

900

800

700

600
NUmber of DIDs

500

400

300

200

100

0
Body Body Body Body Vehicle Vehicle
Powertrain Powertrain Electrical Electrical Chassis Chassis Hybrid Tech Hybrid Tech
Exterior Exterior Interior Interior Personalizati Personalizati
Current Projected Current Projected Current Projected Current Projected
Current Projected Current Projected on Current on Projected
Switches 0 0 0 0 95 300 0 0 0 0 0 0 1 5
Sensor 207 400 0 0 117 234 0 0 23 50 0 0 0 0
Motor 8 24 19 57 0 0 3 9 46 138 3 9 0 0
Lamp 0 0 136 200 0 0 0 0 66 90 0 0 0 0
Actuator 340 500 24 60 106 150 64 90 61 90 16 90 0 30 43
Need

Standardization
• Device Profile ( Device ID + DIDs + DTCs + Configuration + Communication Protocol Requirements)
• Common Set of attributes per category of devices
• Mandatory Requirements - Default set of DIDs and associated DTCs with Access and
Control methods to peripherals

Warranty Spend and Analytics

• Define Failure Effectively
• Identify What data is needed for current and future programs
• Improve Design Assurance and Algorithm enhancements
• Preventive Maintenance – Suggesting Longevity of devices and usage analytics

Enable Framework for Smart Vehicles

• Modular and Re-usable Profiles
• Supplier Agnostic Device attributes
• Pre-existing data points for future vehicle programs
• Remote Command and Control of every device on the vehicle

44
 Baseline, Observations, Plan
What do we have now? What can we add?

Parsed Carmon RDR Services

Parsed Carmon RDR Services

Application Software
Application Software
Low Level Device Abstraction Layer
Device Drivers & Smart Devices Software
Device Drivers & Smart Devices Software

• Harmonize the APIs possible for each device type

• Re-usable & Modular
Lamps Motors Switch Sensor Actuator • Enabling Framework for Connectivity based Applications

45
Baseline, Observations, Plan
What do we have now? What can we add?

Parsed Carmon RDR Services

Parsed Carmon RDR Services

Application Software
Application Software
Low Level Device Abstraction Layer
Tier-1 Conti Tier-1 Denso Tier-1 Visteon Tier-1 Aptiv Tier-1 Hella
Device Drivers & Smart Devices Software

Any Tier-1 or Multiple Tier-1

Customized Interfaces for Each

application as per supplier

Standard Data Collection

Interfaces for each application
DCRs for change in Device or Software

Application Software APIs need

not change for change of device

46
Approach – High Level Objectives
 Expose all Vehicle Data Devices for Command Control and Data Connectivity

 Harmonize the attributes for each device type

 Lamps, Sensors, Actuators, Switch, Motor
 Explore new attributes that have potential for Connectivity now, and reduce warranty in future
 Updates to eSOW, Functional Specs, Part 2 Specs to include new DIDs and DTCs
 Create requirements for Enhancements to Vehicle Services
 Track each requirement (per attribute per device) to completion/ Implementation

 Support Cross Functional teams – VCSE, GDIA, PMTs

 Identify / Check existing process for validating Data Quality in DIDs (in-house) / supplier steps
 Investigate vehicle level view of usage via DIDs captured in a central repository

 Recommendations for Data offloading via CARMON, PARSED, RDR, Services, Apps

47
Inputs Sources
GMRDB Analysis
VSEM
Vehicle Programs and architecture Info
Requirement Management
Electrical Systems Integration – Parts, Components and Device Types
Global Device Transmittals

Warranty Spend GSAR

CV Data PAT Meetings

Analytics Qlikview – Dashboards ( https://www.analytics.ford.com)

Parts Address Data Base – https://www.padb.ford.com/PadbStrutsWeb/treeHomePre.do
Global Commodity Hub
Vehicle Data for Analysis – https://datahub.ford.com/

Specifications Functional

Study Diagnostic
Hardware Specs
Datasheets

Interviews and SMEs and Tech Experts

Brainstorming
Internal Brainstorming

48
Approach to Scale up

• Base Folder Structure based on device types

• Generic Requirements – Master set
• Subset of requirements for sub categories
• APIs applicable
• Vehicle Level Information per Device Type

• Investigate automatic DCR Generation for DTs

involved in a vehicle program
• DIDs
• DTCs
• Protocol Requirements
• Config Requirements
• APIs
• Investigate Traceability from DIDs to DTCs
• Traceability to Test Specifications
• Investigate Monetary aspects of sharing this
Information across suppliers
49
Data Collection Now – Example Lamps/ Switches

• Lamps
• Attributes Information - Generic
• Category Types and examples
• Requirements Template for each category type
• CAN/ Signals/ DIDS/ DTCs
• Low Level Command and Control API (Atomic)
• void I_Lights_SetLEDOnOff(led_id , on)
• void I_Lights_SetLampOnOff(led_id , on)
• Void I_Lights_SetFunctionalConfig( lamp_id , BULB)
• LED_On_Off_Status I_Lights_GetLEDStatus(led_id)
• uint16 I_Lights_GetLEDCurrent( led_id)
• Configuration Information
• Vehicle Level Lamps Information
• DOME_LMPFRNT_LN28 (Lamp ID)
• DT / Part Number for Vehicle Program1
• DT / Part Number for Vehicle Program2
• DCR Info for DT
• HEAD_LMP_LF09
• DT / Part Number for Vehicle Program1
• DT / Part Number for Vehicle Program2
• DCR Info for DT

50
Device Type Sub Categories and Attributes
Actuators Lamps Motors Sensors Switches
• Camera
• LIDAR
• Push Button
• RADAR
• Rotary Knob
• Ultrasonic
• Mechanical • Stepper Motor • Joystick
• Pressure
• Electrical • Induction Motor • 2-way Switch
• Bulb • Temperature
Categories • Hydraulic • Servo Motors • Multi-way switch
• LED • Optical
• Spring • All DC Motors • Rocker
• Load
• Pneumatic • Toggle
• Air Quality
• Roller
• Position
• Touch Screen
• More to Come

• Peak current • Type

• Actuator Type • Usage Counter • Angle Position
• Brightness
• Lifetime/Usage • Activation time • Alignment
• Display Contrast
Counter • Motor Over Load • Temperature • Switch Type
• Color
• Torque/thrust • Motor status • Pressure • Switch ID
• Current
• Pressure • Motor ID • Light • Switch Status
• Voltage
• Speed • Motor Stall Detection • Distance Range • Press/Usage
Attributes • Lifetime -Usage in
• Duty Cycle/ cycle rate • Motor position • Position counter
hours
• Temperature • Average RPM • Vehicle speed • Current
• Lamp Output Status
• Current • CAN Counter (Activation • Current • Voltage
• White Light
• Voltage through Keyfob, fordpass • Voltage • Debounce Time
• LED
• Status app etc) • Direction
• Display Color density
• operating Temperature • Data transmit
• Voltage Rate

51
Attributes in BOLD have few or zero DIDs for most of the Devices
Requirements Management and Release Process
Requirement Specs
DID
DTC
Protocol Requirements
• Create DCRs for additional DID, DTC, CAN, LIN, Ethernet,
API requirements Config , API requirements
• Release to Internal and Supplier teams
• Traceability
• Component to Requirements
Device • Requirements to DTs to Devices to Components to
Types
Test Specs Functions
• DID to DTC Traceability
• Identify what DIDs to monitor for a DTC triggered
Vehicle
DIDs in field
Programs
• Implementation status of each requirement per
program ( Defined, Released, Implemented, etc)
• Test Specifications
Components DTCs • Ensure Component Test specifications have test cases
per attribute/ requirement
• Benchmarking Supplier quality data

• ESOW Update
• Device Data
Attributes –eSOW
• PDL Update
• Appendix to PDL

52
Release artifacts examples

53
Collaboration with CV Data Teams on Warranty spend

Discuss Analyze Identify Create Recommend

• CV Data Meetings for • GMRDB For Existing • Unused bits in GMRDB • DID Requirements • DID Memory location
Warranty spend Identifiers to bit level • New CAN Signals • DTC Requirements • Effective method for Data
• Internal Brainstorming • Existing CAN Signals Offloading
• SMEs and Feature
Owners

54
References

Wiki - All Vehicle Data and Control (AVDC)

http://wiki.ford.com/pages/viewpage.action?pageId=209487173

GitHub - https://github.ford.com/sw-architecture/avdc

55
 Thank you
Paritosh Gautam (pgautam1) – Cloud to Vehicle
Medha Karkare (mkarkare) – Camera Architecture and Use Cases
Ravi Chalanti (rchalant) and Team – Standardization and exposing more device information and device control
Don Walsh (dwalsh7), John Ricks (jricks7), Jim Weinfurther (jweinfur) – Body domain CAN message patterns for Services

Access to “source” material: EESE Wiki

Visit Application Policy Service site (http://www.accessmgmt.ford.com/)
• At the Request Access box, click Go
• Select All Application Domains and search for EESEWiki

Q&A • Choose EESEWikiUser role under EESEWiki. Click

on Request Access
• Include justification in the Note to Approvers box to avoid
delays/rejection.
• Submit the request and wait for approval.
• After approval, access may take up to a day to take effect.
Email Ian-Artemius Bantilan for any questions.
Note: Users who haven't accessed EESEWiki in a 90 period will have
their licenses revoked so licenses can be used by those who need it.
56