Glossary

ECU

An ECU (which also includes electrical devices), refers to the controller hardware that is put into the vehicle. An ECU can have:

  • 1 or more hardware revisions.

  • Multiple flashable locations in vehicles.

  • Multiple different software components that can be loaded.

ECU Assembly

An ECU Assembly is a unique bill of materials for an ECU which specifies:

  • Which ECU (and hardware revision) is used.

  • Which software part numbers must be installed.

  • Where it goes in the car.

Note

Note: An ECU Assembly does not specify the revisions of the software part numbers. That is specified when creating packages for specific releases.

Some examples of ECUs with multiple assemblies:

  • Motor controller (MTC), is in the car as the FCC, RLC, and RRC (3 locations, same HW, same SW).

  • The IHUB, has 3 assemblies. A combination of older hardware, with software for most Beta cars, a combination of older hardware and different software for marketing cars, and a new version of hardware will be arriving soon.

  • String control units, and current sensors are all duplicated 6 times (one for each string in the battery pack).

Electrical Device

What is an Assembly vs ECU vs Electrical Device: - An ECU is a unique type of hardware. - An electrical device is sensor or other item that has an EDCS, but is not flashable. For the purposes of this tracker, electrical devices are ECUs.

Instance

An instance is an ECU assembly that is specified to be in a specific location in the vehicle. Due to how Over the Air (OTA) files work, each OTA flashable file has information about where an ECU is in the vehicle. This means that every instance must be a different ECU assembly for the ECU tracker tool.

Variant

A single ECU can have multiple assemblies which means there can be multiple variants of the ECU. Similarly, each domain will have a different bill of materials (BOM), for different vehicles. The ECU tracker supports different ECU variants as ECU assemblies, and different domain or vehicle variants as different BOM objects.

Car/Vehicle

A car/vehicle is a bill of materials for a specific variant of vehicle. It is also the top level of the BOM hierarchy.

Domain

A domain has multiple meanings. A domain BOM is a bill of materials for a specific domain variant. A domain is a logical grouping of which ECUs are tested together for subsystem validation. A domain is the middle layer of the BOM hierarchy.

BOM

Bill of Materials (BOM) are objects that can be used to specify what goes into different vehicle variants. ECU assemblies, Domain level BOM objects and car level BOM objects are all BOM objects. Note, the bill of materials should specify everything to the level of hardware and software part numbers. It does not specify specific versions.

Group

A group specifies which BOM variants are packaged together for package creation (and likely validation). For example, all ECU assemblies for the String Control Unit (SCU) are in the same group so that a single SCU package is created which has instructions and files for flashing all the SCUs. For BOM objects, all variants of the battery domain would be in the battery group, so there is a single package for all the battery variants. As FF approaches Gamma, we will need to decide whether to have separate groups for Beta and Gamma or not. Where most of the software overlaps, fewer groups means fewer packages. Where software is mostly different, it would make more sense to have separate groups, and create more packages. Every group will correspond to a package that must be created, and promoted.

Flashable

Is your device considered flashable? Your device is NOT flashable if it meets ALL of the following 4 conditions:

  1. No FF engineer can flash software on it.

  2. No FF engineer can verify the version.

  3. Every physical item in our inventory has the same (or no) software in it.

  4. The next version of software we get will either be flashable by FF engineers or the version will be read.

Note

Note: If there is ever a situation where we have parts where we can’t read the version, can’t flash software, and there are different versions in inventory, they must be treated like different hardware parts.

Manifest

A manifest is a listing of what software gets installed on what hardware for a specific bill of materials and a specific version. There can be manifests for different ECU assemblies, manifests for different domain variants, and manifests for vehicle variants (specific cars). Manifests exist physically as .csv files for humans to use, and .pkg and .swpkg files for OTA systems to use.

Software Component

A software components is a single file that can be independently flashed into an ECU. A component can refer to a bootloader, an app, or a calibration for most ECUs. For android ECUs, a component is the entire flashable .zip file.

Package

A package exists both as a physical folder location on the P:\FirmwareBuilds directory and an object in the ECU tracker. A package is everything that is needed to flash an ECU assembly, or Domain, or Vehicle either manually or via OTA. Every group in the ECU tracker will have its own packages for different releases. It contains:

  • Human readable manifests for every BOM in the group.

  • OTA manifests for every BOM in the group’

  • Links to where to find the necessary components on the P: drive (which are likely in different folders).

  • ECU level packages directly contain their own .ecm (OTA flashable) files.

Exported Package

An exported package is a package that has been moved to a different folder, and it contains all of the components and .ecm files that are needed to flash in a single location. This would be used for taking an accepted package and importing it into ENOVIA, or to create a package for use in the field where P: drive access would be slower.

Promoted

A package is promoted when it is has been tested sufficiently to allow it to be used in the next phase of validation or usage. All ECU level packages (used by a domain level package), must be promoted before the domain level package can be built. All domain level packages must be promoted before the vehicle/car level package can be built. A vehicle level package must be promoted before it can be used across the fleet.

Software List

A software list is a list of what software would get loaded together on to a software address. For example, on some ECUs, some of the software gets loaded on to one processor, and other software gets loaded on to a 2nd processor. In this case two lists are necessary. Lists are also needed when different ECU assemblies have different software loaded on to them. Each list specifies: - What specific pieces of software are used. - Their flash order. - What vehicle releases this list can be used on.

Software List Type

A Software list type is a grouping of lists. - A list is specific to one or more releases. - A list type encompasses all the lists use-able across all the versions.