search

elisa-tech / wg-automotive

Creative Commons Attribution Share Alike 4.0 International
12 stars 15 forks source link

readme

ELISA Automotive WG

Mission statement

The automotive workgroup discusses the conditions and prerequisites the automotive sector needs to integrate Linux into a safety critical system.

We focus on actual use cases from the Automotive domain to derive the technical requirements to the kernel as a basis for investigation within the Safety Architecture Workgroup and to serve as a blueprint for actual projects in the future.

This repository contains agreed upon and peer reviewed material for this work group, see process description below

Use case

Currently, the Automotive work group focuses on the tell tale use case, i.e. warning symbols in the intstrument cluster of a vehicle, typically rated with ASIL B.

Getting in Contact, Getting Involved

Mailing list, Calendar etc

Subscribe to our mailing list: https://lists.elisa.tech/g/automotive

Meetings

The Automotive workgroup currently meets once per week.

As meeting times may change always check the web calendar associated with the mailing list for up to date information about all workgroup meetings. Consider subscribing to keep up to date!

Meeting minutes are kept at https://docs.google.com/document/d/1qgEkB6HBjq0ojoTSmI_E18BZco3lORK1ZZDrBH1YQo0/edit#heading=h.b7qah2h40uzb

Newcomer Onboarding Checklist

We welcome newcomer. If you don't find your way forward, most likely it is on the WG to improve documentation. Just join one of the weekly meetings or drop a mail via the mailing list.

Other than that, here is a checklist to get you started:

ELISA Automotive WG - Navigation and file locations

Google drive workgroup folder

The google drive is used for drafts, presentation and general material that has to be considered work in process. The gdrive also is used for the meeting minutes.
https://drive.google.com/drive/folders/1FCEzywCMfk3wY6lxBoMYjfQ_DQ44S5YS

Repo Orientation regarding the tell tale use case

Original considerations

The originial considerations of the Use Case can be found in the subfolder "Initialy_discussed_system_scope" of this repository

First iteration of the use case (demo implemenation focused)

The first iteration of the use case, that the meta-elisa demo is based on, can be found in the subfolder "AGL_cluster_demo_use_case" of this repository

Our Implementation on top of the preexisting AGL Cluster demo is split in two repositories:

Second iteration of the use case (STPA analysis focused)

The second iteration of the use case includes the ongoing STPA analysis can be found in the subfolder "Cluster_Display_Use_Case_v2"

The models are also visible via github page deployment as online viewer at:

https://elisa-tech.github.io/wg-automotive/

(Note: svg graphics cannot be rendered with every browser directly. Chrome engine may be a good choice. The html export might not always be up to date with the models, generation is not automated.)

Tooling

Requirements

Requirements and Safety concepts are stored and handled as Freeplane Mindmap using the Functional Safety Addon specifically developed for the task.

Mindmap Example

SysML modeling

SysML models are done with Eclipse Papyrus with SysML v1.6 Plugin

Contribution workflow

The automotive working group uses the following github based workflow as base for contributions.

Prerequisites

Git Newbie section

This section serves as reference for members new to GIT, to be read on demand. All the GIT black belts out there can stop reading at this point in good concience.

Intital Setup - Git etc

For this workflow, having Git installed and configured is essential.

Linux users install the git package, Windows users grab git for Windows click.

Both groups need to provide Name and email adress to git:

git config --global user.email "you@example.com"
git config --global user.name "Your Name"

Depending on your preferences and love/tolerance of the commande line, you might also want to get a graphical GIT interface such as

Short example using command line git in the top level folder to fetch the latest revision and create a new branch by the name of "my_feature": Assuming your fork is on par with the upstream repository, fetch origin to get the revisions to your local clone

git fetch origin

Create your feature branch based of origin/master: note the flag --no-track to avoid tracking origin/master, since we are constructing a new feature branch.

git checkout -b my_feature --no-track origin/master

Push the new branch to your fork on github and make your branch track it:

git push -u origin my_feature

Committing and pushing

Signing off and DCO

Using the --signoff flag when committing conveniently adds the signoff line to your commit message

Signed-off-by: <your name> <<your email adress>>

What if I forgot? Github will complain when you create a pull request, having signed commits is required! How to fix it then? Signing off on the last 3 commits for instance is done by rebasing the current branch on an earlier commit:

git rebase HEAD~3 --signoff

Keep in mind, since this changes the history of the repo, if you already pushed, pushing again to overwrite the changelog requires using the --force flag!

Syncing Your fork and local working copy with the upstream repository

Before starting your work, you need to make sure the files you start out with are up to date to avoid having to fix that afterwards. This workflow involves three relevant destinations

To ensure your files are up to date, your fork needs to be syncronized with the upstream repository to pick up any changes merged since the last time you synced your fork. This sync can be done in the github browser interface with just one click, provided your master branch has no conflicts with the master branch of the upsream repository. To ensure this property, its best to never commit to the master branch of your fork at all. Github description: https://docs.github.com/en/github/collaborating-with-pull-requests/working-with-forks/syncing-a-fork#syncing-a-fork-from-the-web-ui

With your fork syncronized with the upstream repository, we have to make sure any new commits picked up from the upstream repository are propagated to your local clone. Assuming you refrain from committing to your master branch, the changes can be pulled and fast forwarded: Command line GIT example with a shell opened in the directory of your local checked out copy:

git fetch origin
git checkout master
git pull origin --ff-only

The flag --ff-only restricts the pull operation to fast forward merges, this operation will fail if the current revision in your local copy is not a direct ancestor of the upstream revisions to be pulled, i.e. if you by mistake committed to your local master branch. For a detailled explanation why that would be highly undesirable even if the merge has no conflicts see click

After these two steps, the master branch of all three repositories are synced up, you can inspect the latest revision in the master branch and you are prepared to base a feature branch on synced up master branch.

Rebasing a Feature Branch

While you worked on your feature branch, other pull request might have been merged into the master branch of the upstream repository. Since could lead to conflicts when merging your branch, you need to make sure that your feature branch is based on the current revision, not the one you started your work with. This we accomplish by a two step process

Command line git example:

git fetch origin
git checkout my_feature_branch
git rebase origin/master

In case of conflicts, rebase will interrupt the process, give you a chance to resolve the conflict and continue. For a detailled description of the process and commands involved, see click

Now your feature branch is based on the most recent master branch and can be merged without conflicts. Pushing your rebased feature branch to your github fork requires the use of the -force flag, since rebasing changes the commit history already present in your fork.

git push origin -force