Package Creation and Building

Overview Below is the comprehensive documentation for creating packages using ECU Tracker.

Author

Daniel

Date

Nov 01, 2021

Version

7.4.0

Contents:

• Vehicle Package Inheritance
  • Inheritance Editor

Introduction

For each ECU or Electrical Device there can be several different ECU Assembly of different Instance For each Domain there can be several Variant objects with different BOM s for each domain variant. For the Car/Vehicle, there will be different Variant s with different BOM s for each car type.

Which instructions to follow

• All Packages are now built by Jenkins. However, not all components are built by Jenkins.

• Supplier ECUs have components built by the suppliers (but packages built by Jenkins).

• Some in-house ECUs have components built by Jenkins, and packages built by Jenkins.

• If you can click a button in Jenkins and get a resulting .zip or .hex file, your ECU is “Built by Jenkins”.

Rules with multiple assemblies

If there are 2 or more different versions of a component, i.e. 2 different SCU_Apps, or 2 different SCU_CALs there are special rules:

• They shall not the same part number.

• They shall not have the same version. If they had the same version, than during development while the version is broadcast but the Pnumber is not, it cannot be differentiated.

• The version in the tracker shall be detailed enough so that the 2 variants can be differentiated from each other. It would be unacceptable to have the version listed as 0.13RC1 if 2 different ECUs have 0.13RC1, the subminor must be specified. i.e. 0.13.RC1.18.11

• They should not share a start_string. If there are 2 items SCU_App.hex or 2 different files found by ‘SCU_App’, the tracker cannot update version numbers for you. This is ok, but it should be avoided when possible.

DRE: (with components built by Jenkins) Creating a Package

Specify Software

1. For any new software that the ecu tracker will build, right click and add a new software line item.

2. Go to the Softwares tab.

3. Go to the Bottom Detail: “Softwares”.

4. Fill in all of the fields other than file path.

5. Leave built = false.

6. For the version just put Major.Minor (MM.mm)

7. When Jenkins builds the package it will fill in the full version, and the full file path for you.

8. For field details see Software Fields Details.

Specify Software List

1. Go to the Softwares tab.

2. Go to the Top Detail: Software List Types.

3. See if there is an old software list that can be reused.

4. If so, right click on the left half of the Software List Detail, and add a new version to the list.

5. If not:

   1. Right click on the software list type which will contain the software list.

   2. Click add software list.

   3. Name the software list with a unique descriptive name.

   4. Click on all the other software lists in the same software list type. Make sure none of them have the version you are about to build listed.

   5. If necessary right click and delete the version from an old list. This only happens when the old list is part of a failed package.

   6. Right click and add the release version to the newly created list.

   7. On the right half of the Software List Detail:

   8. Right click to add an item

   9. Select the software from the drop down list.

   10. Ensure the flash order is correct. (it can be 0 based or 1 based)

6. Build the package following the instructions on Create/Build a Package.

See TroubleShooting

Note

For some in-house ECUs, Jenkins creates a BL, and a BLU at the same time, but it only has a BLULogistics.json If this is the case, the Jenkins job can only update the tracker tool for the BLU, and not the BL. To build these packages takes 2 attempts. On the first attempt, it will build the BL and BLU, but it will only update the BLU in the tracker. The BL information must then be manually updated. Afterwards, try building the package a 2nd time. It will build tha app if needed, and it should successfully build the package.

Guidelines or priorities with multiple assemblies

One branch

Having Sconstruct handle multiple variants in the same branch is the long term solution.

1. Sconstruct must be modified so that a single release branch and Jenkins job creates all variants.

2. Sconstruct and scons either has to put information for the multiple variants into the existing LogisticsData.json or multiple .json files.

3. Sconstruct must ensure that subminor is different for the different variants.

4. The ecu tracker will need to be updated to handle the multiple .json files.

5. In the short term, some of the file path and “built” fields would need to be filled in by hand.

More than one branch built by Jenkins

The better short term solution is to have 2 different release branches built by Jenkins.

1. Both branches must use the official shareddbc branch.

2. The ‘Release Branch’ field of the softwares tab can be used to tell the ecu tracker and Jenkins to use a non-standard branch.

Manual Upload

The least preferable option is to manually upload code.

1. A supplier style job can be created for your ECU.

2. See Uploading .zip files using Jenkins.

3. Ask Jaepyong Kim or send an IT helpdesk ticket to request this job be created for you if needed.

4. The Variant .zip file(s) will be uploaded through the supplier style job.

5. The tracker for built and file path must be updated manually.

DRE (supplier based, or in house built separately) Creating a Package

1. Uploading .zip files using Jenkins

2. Adding the software components to the tracker

3. Adding A Software List

4. Using the Package Page

• Supplier or non Jenkins ECUs

Uploading .zip files using Jenkins

1. Make sure your .zip file follows the naming convention: Jama Requirements.

2. Go to Jenkins job for your ECU or default (Supplier-ECU-ReleaseCandidate).

3. Go to Jenkins Supplier Jobs.

4. Login to Jenkins.

5. Scroll down and find the job such as (default) Supplier-ECU-ReleaseCandidate.

6. Make sure your .zip is in \\faradayfuture.com\softwaredev\Supplier_Temp.

7. On the left side click “Build with Parameters”.

8. Fill in the form

   1. For File_Name: put the filename with extension (but not the full file path).

   2. For Vehicle_Name: put “DF91”.

   3. For Release_Name: put “DF91_M.mm” where M is the major version and mm is the minor version.

   4. For ECU (default supplier job): Select the ECU name from drop down list.

9. Hit Build.

10. Look for your file in //faradayfuture.com/softwaredev/FirmwareBuilds/${VEHICLE_NAME}/ECU_ReleaseCandidate/${RELEASE_NAME}/Suppliers/${ECU}/

11. If the “Build with parameters” does not show up, please submit a helpdesk ticket.

Uploading supplier .zip files from tracker

Note

This feature is available from version 6.0 and only support Supplier ECU

1. This feature is using the default Supplier-ECU-ReleaseCandidate. job.

2. Please make sure your ECU is in the Job ECU List. Contact tracker support if your ECU is missing from the select list.

3. Make sure your ECU is Supplier ECU.

   1. Go to ECU window, select your ECU in the ECU list.

   2. Check the Supplier ECU.

   

4. Got to Softwares window, select your ECU in the ECU list.

5. Select the target software and right click on the File Path field.

6. Select Upload Supplier Zip in the right click menu.

   

7. Select Vehicle Folder (Release).

8. Select zip file using the Folder button

9. Hit OK to start uploading.

   

Adding the software components to the tracker

1. Go to the ECU tracker.

2. For every software component, add a row to the Softwares Tab, software list at the bottom.

Note

For 0.13 only, you may modify existing items in the list with a new file path.

See also

Software Fields Details if necessary:

Adding A Software List

1. If any new software items were added, go to the software lists in the top.

2. Right click on the SW list type to add a sw list.

3. Right click in the Versions section to add the targeted release version.

4. Right click in the rightmost tab to add software items:

   1. Pick the software item from the dropdown list.

   2. Enter the flash order: For some items such as a bootloader, you can either run a bootloader updater, or you can load the bootloader via JTAG, but you do not need to do both; either one is fine. If this is the case, use the same flash order number for the bootloader updater, and for the JTAG bootloader, this indicates that the person flashing can do either one.

   3. Required_Bootloader: Put in the minimum bootloader version in order to flash this item. By default, the list will show you previous bootloader versions or N/A if you are loading something via JTAG. However, if the bootloader restrictions are more detailed, you can type whatever is needed in this field.

   4. Flash_Tool: Pick the required flash tool from the drop down list. If your item is not shown, you can type in a new option.

   5. Notes: If there are any special instructions, this can point to a file to read, or contain text for anything that somebody would need to know to flash your ECU.

Reusing a Package

1. Find your package Find any existing packages.

2. The existing package should have previously built successfully and promoted to success.

3. In the Versions window, right click to add new version for which you are reusing the package.

4. Next, promote the package to success for this new version.

Using the Package Page

Find any existing packages

1. Fill in the level from the dropdown box.

2. Fill in the group from the dropdown box.

3. Select the desired version from the dropdown box in the top right.

Note

If reusing a package, search for it under the previous version.

Create/Build a Package

1. Either select a package which is not built, or to create a new package, fill in the level, group, and version.

2. Hit the Create/Update button in the top left.

3. Enter your Jenkins username and password.

4. There will be an option, “Allow build without ECMs”. Try this with No. If the build fails because it can’t create .ecm files, try again with Yes, and work with the OTA team to figure out why the .ecm creation failed.

Warning

If you are building a Domain level package, please ensure all ECUs under that domain have been promoted. Only then will the Domain package be built successfully.

Software Fields Details

1. Software: A unique name for this component. It should include some version info in the name to keep it unique. Note, when creating ecms, it will use this name.

2. Built: True once the file has been built.

3. Version: This should be Major.Minor (MM.mm) before building, and Major.Minor.RC[RC].Subminor.BuilderID after building.

4. Flashing Level: What level of bootloading is expected based on bench tests?

5. Component Type: Pick from drop down. All is reserved for android packages. With Jtag, the likely answer is App.

6. Start String: There are different rules for supplier vs in-house ECUs.

   1. Android or QNX ECUs: The Start strings must not be duplicated within any software list, or duplicated within single ECU Assembly. For example, no duplicates inside the IHUB_EVT2.0_SURROGAtE assembly, however, the same start string can be used in IHUB_EVT2.0 SURROGATE and within IHUB_EVT2.0_VISTEON. Furthermore, if the software component is being used for OTA flashing for Android or QNX, the start string must be chosen from the following list.

      Note

      Note: It is possible to have an ECU have some processors be Android and some be simple processors. In that case follow the Android vs Other instructions on a software component by software component basis.

      1. SWOTA_REAR_DISPLAY_CONTROLLER (future when rear display controller gets software)

      2. SWOTA_MULTI_MODEM_UNIT (mmu)

      3. SWOTA_MPC (mpc)

      4. SWOTA_HPC (hpc)

      5. SWOTA_ADAPTER (iab)

      6. SWOTA_HYPERVISOR (future when the IHUB gets a 3rd component the hypervisor?)

   2. Other ECUs: See Jama Requirements. The start_string must be the ECU, the component type, and the Variant type if necessary. It should not contain any version info. The start_string will be used for in-house ECUs to kick off Jenkins jobs, so make sure it is typed in correctly. If a new start_string is added for an in house ECU, please let somebody on the tools team know so that they can connect the proper Jenkins job.

7. Component Number: This is the component number for flashing and/or reading back the version. For most components, the component number for flashing and reading is the same. However, for some components, such as bootloader updaters, the component is flashed to location 2, but the version is read from location 1. If the flash, and read locations are the same, enter a single number. If it can’t be flashed using UDS, and it can’t be read via UDS, or the periodic version message, put N/A. If it is flashed on one address, and read on another put the flash address first, then the read address separated by a comma. i.e. ‘2,1’. If it is flashed via JTAG, and can be read, put N/A as the flash part, and the read address as the 2nd part. i.e. ‘N/A,1’

   Note

   Note: Component number is also known as the ID field from the DSA tool. See the bootloader spec for more details.

8. PNumber: The component software part number as soon as it is known.

9. Owner ID: Enter your email address.

10. FilePath: Put in the full file path to the file starting with P:for ECUs uploaded using the supplier method. For ECUs compiled by Jenkins, the file path is filled in for you.

11. Description: Whatever you want here.

12. Release Branch: Leave this blank for supplier ECUs, or if your release branch is the standard release branch such as /release/DF91_0.13 Fill this in with whatever comes after /release for non standard release branches. For example if your release branch was /release/MYVARIANT_DF91_0.13 enter MYVARIANT_DF91_0.13

Pre-Conditions

1. Pre-conditions are needed to help with OTA

2. It tells the VUM (Vehicle Update Manager) how to flash and what it needs to consider before flashing

3. So for example you can tell the BPG_21APP, has preconditions where it depends on some version of BGW_21App, or BPG_21Cal

4. The are added to the OTA package created for each component

5. To add pre-condition, right click any row and select Preconditions Settings

6. If there is already a pre-condition defined the icon to the left of software name would be green

7. From the right click pop-up dialog, select Add Precondition Group from bottom right. Currently only one group is selected

1. Then select the Add Precondition for group A

1. You need as many rows as the number of other component your current component depends on

2. Then please fill out the precondition accordingly, please see details for each field below

Field	Description
component id	The component ID you want to refer this to
ecu id	The ID of the ECU you want this for
ecu name	Name of the ECU
firmware part number	Firmware part number of the component you are refering to
hardware part number	Hardware part number of the component you are refering to
newest acceptable firmware rev	The newest acceptable firmware rev of the component
newest acceptable hardware rev	The newest acceptable hardware rev of the component
oldest acceptable firmware rev	The oldest acceptable firmware rev of the component
oldest acceptable hardware rev	The oldest acceptable hardware rev of the component

Note

1. All fields are optional, so if you are not sure please leave the field empty

2. The ecu id, name, component id are for the ecu for which you are refering, so for example you can refer to BGW’s component 2 while doing pre-conditions for BPG APP

3. Newest/Oldest is to define a range, so you can define that for BPG App 21 you need BGW App from 15 to BGW App 20

How to Add Release Notes

For more info please see Release Notes

TroubleShooting

The following are the areas to look at.

1. Information in the tracker is not correct, it does not kick off any Jenkins jobs.

2. The Jenkins Job for a component is failing.

3. The Jenkins Job is creating a component but not updating the tracker.

4. The Package Building Job is failing.

Information in the tracker is not correct, it does not kick off any Jenkins jobs

1. Look for something such as ERROR: package [My Package Name] is not ready because …

2. There is a string which should show what to fix.

The Jenkins Job for a component is failing

1. Look for ERROR: Jenkins Job [job]: failed.

2. Go to the Jenkins Job listed in the log.

3. Look at the Console View.

4. Look on the P: drive, P:FirmwareBuildsDF91ECU_ReleaseCandidate under the appropriate release folder.

5. If your software does not exist, look in depth into the Console Output. Software experts such as TBD can help.

The Jenkins Job is creating a component but not updating the tracker

1. Look for ERROR: Jenkins Job [job]: failed.

2. Go to the Jenkins Job listed in the log.

3. Look at the Console View.

4. Look on the P: drive, P:FirmwareBuildsDF91ECU_ReleaseCandidate under the appropriate release folder.

5. If your software does exist, your software was built, but it was unable to update the ECU tracker.

6. Temporary work around

   1. Go to the Softwares Tab.

   2. Edit the software file (files) that were just built.

   3. Set Built to True.

   4. Fill in a more detailed version number (must include a RC).

   5. Fill in the filename.

7. Medium term solution(s)

   1. The project_ID in the .json must be the ECU name.

   2. Make sure that start_string is equal to “PROJECT_ID”_”APPLICATION_TYPE”

8. Longer term solution(s)

   1. There will need to be changes to the format of LogisticsData.Json (or multiple files) when a single Jenkins job creates more than one .hex.

   2. Make sure that start_string is equal to “PROJECT_ID”_”APPLICATION_TYPE” or “PROJECT_ID”_”APPLICATION_TYPE”_”VARIANT_TYPE”.

   3. There will be new items to add to the LogisticsData.json so that more information can be automatically added to the tracker.

The Package Building Job is failing

1. After the job is run, in the Package Detail “Built” is None or Failed.

2. Look at the build log in Jenkins.

3. The most common cause is that .ecm files could not be created.

4. See if it attempted to create the .ecm files appropriately.

5. If .ecms were attempted and failed:

   1. Review the .scr file information.

   2. Speak to the OTA expert (TBD).

6. If .ecms were not attempted:

   1. Double check that the start_string can locate the .hex file in the .zip file.

   2. Double check the .zip file follows our naming conventions.

   3. Double check that the files are marked as compliant or not compliant properly under flashing level.

Other errors

No jenkins jobs listed for start_string:

Double check the start_string. If it is correct, contact daniel.disler@ff.com to add the proper jenkins job for that start string.

No package with package name [package_name] found:

A domain or vehicle level package is missing one of the ECU or domains that should have previously been built.

• package [Package] failed the following manifests were not built

• package [Package] failed with exception

• More than one package found with package name [package_name]

• after running jenkins job(s) [Job Name], the software [Software] is still not built

• Jenkins Connection not initialized, please try again. STOPPING

1. Scroll to the top of the log window, and find the log “INFO - Logging from file location: [File location]

2. Email the log to daniel.disler@ff.com and abhijit.bansal@ff.com

Video Tutorials

• In house Jenkins ECUs

• Supplier or non Jenkins ECUs