Skip to content

Commit f1219d0

Browse files
prillerpprillerp
authored
Merge pull request #83 from CSA-FEDERATE/Add_Shift2SVD_BBs
Add shift2 sdv bbs
2 parents 48ab4bf + ae71dd2 commit f1219d0

File tree

3 files changed

+266
-0
lines changed

3 files changed

+266
-0
lines changed

‎BB-EST/Requirements/.gitkeep‎

Whitespace-only changes.

‎BB-EST/Software-Development-Kit/BB_API_verification.md‎

Lines changed: 133 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,133 @@
1+
2+
# API verification
3+
4+
## BB Tags(s)
5+
<!-- Tag(s) define in which area(s) (cloud, in-vehicle) the BB is executed, and what type of BB it is (tool, process, microservice) -->
6+
BB-CEST, BB-EST
7+
8+
## Functional Clusters
9+
<!-- In which Functional Cluster the BB be located; if none of the existing fit new required -->
10+
11+
## Layer
12+
<!-- AppLayer, MWLayer, OSLayer, HWLayer -->
13+
14+
## BB Usage
15+
<!-- example on how to use BB or link to documentation -->
16+
17+
## Known Implementation
18+
19+
## ID (unique name)
20+
21+
## Description
22+
<!-- General Description of the BB -->
23+
API verification shall provide a tooling that checks if the code of an application is using all APIs correctly and in which vehicles the APIs are available.
24+
25+
## Rationale
26+
<!-- Explanation why we need the BB; what problem want to be solved -->
27+
28+
## Governance Applicable S-BB(s)
29+
<!-- Reference to e.g. UN/EU CRA Cyber Resilience Act; UNECE 156 - Software update and software update management system
30+
Reference to defined S-BB(s)
31+
Reference to e.g. IS026262, AUTOSAR Spec. X -->
32+
33+
## Compose BB(s)
34+
<!-- Link to required BB(s)
35+
E.g. BB-SC StateManagement
36+
BB is a composition of other BBs -->
37+
38+
## What is needed to Design and Implement
39+
<!-- e.g. we expect to have a certain HW capability and or SW environment or Tool support, or a documentation, or an extra audit, or Test, or Compiler, or Prog. Language, … -->
40+
41+
## What is needed to build and run
42+
<!-- e.g. we expect to have a certain HW capability, or Runtime Environment, or Pre-configuration, or Code-signing, or Test, … -->
43+
44+
## Non-Functional Requirements
45+
<!-- With respect to Safety, Security, Realtime, … -->
46+
47+
## Dependencies to other Clusters
48+
<!-- Other clusters are needed. FC Security, FC Storage, …
49+
e.g. If FC Security : Security BBs are needed but you can choose for example crypto BB-SC from company A or crypto BB-SC from company B; several compositions may work -->
50+
51+
## Vehicle API Relevant
52+
<!-- If “Yes exists” – where – e.g. COVESA VSS
53+
If “No” – nothing more to do
54+
If “Yes, proposal for additional Signals/Information – what should be made available, and where e.g. via (COVESA) VSS/VISS -->
55+
56+
## Author/Company
57+
58+
## Priority
59+
<!-- High, Medium, Low -->
60+
61+
## Related Project(s)
62+
<!-- If Yes – e.g. The BB should be used/added in the Eclipse Blueprint A – for demo purposes, show added value,
63+
If No – Project Proposal (e.g. WP4 in FEDERATE, or in the SDV EcoSystem Community Framework -->
64+
SHIFT2SDV
65+
66+
## Availability of Source Code
67+
<!-- Yes / License (e.g. Yes/MIT)
68+
No – Commercial Closed Source -->
69+
70+
## Availability of API
71+
<!-- Yes / License (e.g. Yes/Apache 2.0)
72+
No - Commercial -->
73+
74+
## Type of API
75+
<!-- Web API, Library/Framework API, Operating System API, Database API, Remote API, Hardware API, Other -->
76+
77+
## Potential obstacles
78+
79+
80+
## Maturity Badges
81+
<!-- taken over from Eclipse SDV Process
82+
See Definition of Badges and their Flavors
83+
https://gitlab.eclipse.org/eclipse-wg/sdv-wg/sdv-technical-alignment/sdv-technical-topics/sdv-process/sdv-process-definition/-/wikis/Definition%20of%20Badges%20and%20their%20Flavors
84+
85+
86+
| | Documentation | Requirements | Coding Guidelines | Testing | Release Process |
87+
| --------- |:-------------:|:------------:|:-----------------:|:-------:|:---------------:|
88+
| Gold | Badgelevel | Badgelevel | Badgelevel | Badgelevel | Badgelevel |
89+
| Silver | Badgelevel | Badgelevel | Badgelevel | Badgelevel | Badgelevel |
90+
| Bronze | Badgelevel | Badgelevel | Badgelevel | Badgelevel | Badgelevel |
91+
| No | Badgelevel | Badgelevel | Badgelevel | Badgelevel | Badgelevel |
92+
| NotDefined| Badgelevel | Badgelevel | Badgelevel | Badgelevel | Badgelevel |
93+
94+
Options:
95+
NotDefined/No/Bronze/Silver/Gold
96+
97+
Example:
98+
| | Documentation | Requirements | Coding Guidelines | Testing | Release Process |
99+
| --------- |:-------------:|:------------:|:-----------------:|:-------:|:---------------:|
100+
| Level | [Gold](urlToDoc)| No | Notdefined | Bronze | [Silver](urlToDoc) |
101+
102+
103+
-->
104+
105+
## State (+ date of last change)
106+
107+
<!--
108+
- Incubating (no code yet)
109+
- Implementation started
110+
- First public release available
111+
- Used in production by 1 OEM
112+
- Used in production by >1 OEM
113+
- Abandoned
114+
-->
115+
Implementation started
116+
117+
## System Context
118+
119+
<!--
120+
OS and runtime/framework requirements
121+
122+
eg.
123+
124+
- AGL
125+
- QNX
126+
- ROS-based
127+
- container runtime
128+
- web assembly
129+
- web service
130+
-->
131+
132+
## Bazel compliance status
133+
<!-- The S-CORE project requires all BB contributions to be ready for BAZEL compliant (https://github.com/bazelbuild/bazel)-->

‎BB-EST/Software-Development-Kit/BB_Library_and_variant_management.md‎

Lines changed: 133 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,133 @@
1+
2+
# Library and variant management
3+
4+
## BB Tags(s)
5+
<!-- Tag(s) define in which area(s) (cloud, in-vehicle) the BB is executed, and what type of BB it is (tool, process, microservice) -->
6+
BB-CEST, BB-EST
7+
8+
## Functional Clusters
9+
<!-- In which Functional Cluster the BB be located; if none of the existing fit new required -->
10+
11+
## Layer
12+
<!-- AppLayer, MWLayer, OSLayer, HWLayer -->
13+
14+
## BB Usage
15+
<!-- example on how to use BB or link to documentation -->
16+
17+
## Known Implementation
18+
19+
## ID (unique name)
20+
21+
## Description
22+
<!-- General Description of the BB -->
23+
Library and variant management shall provide a tooling that provides application developers effective access to vehicle APIs and that manages API libraries.
24+
25+
## Rationale
26+
<!-- Explanation why we need the BB; what problem want to be solved -->
27+
28+
## Governance Applicable S-BB(s)
29+
<!-- Reference to e.g. UN/EU CRA Cyber Resilience Act; UNECE 156 - Software update and software update management system
30+
Reference to defined S-BB(s)
31+
Reference to e.g. IS026262, AUTOSAR Spec. X -->
32+
33+
## Compose BB(s)
34+
<!-- Link to required BB(s)
35+
E.g. BB-SC StateManagement
36+
BB is a composition of other BBs -->
37+
38+
## What is needed to Design and Implement
39+
<!-- e.g. we expect to have a certain HW capability and or SW environment or Tool support, or a documentation, or an extra audit, or Test, or Compiler, or Prog. Language, … -->
40+
41+
## What is needed to build and run
42+
<!-- e.g. we expect to have a certain HW capability, or Runtime Environment, or Pre-configuration, or Code-signing, or Test, … -->
43+
44+
## Non-Functional Requirements
45+
<!-- With respect to Safety, Security, Realtime, … -->
46+
47+
## Dependencies to other Clusters
48+
<!-- Other clusters are needed. FC Security, FC Storage, …
49+
e.g. If FC Security : Security BBs are needed but you can choose for example crypto BB-SC from company A or crypto BB-SC from company B; several compositions may work -->
50+
51+
## Vehicle API Relevant
52+
<!-- If “Yes exists” – where – e.g. COVESA VSS
53+
If “No” – nothing more to do
54+
If “Yes, proposal for additional Signals/Information – what should be made available, and where e.g. via (COVESA) VSS/VISS -->
55+
56+
## Author/Company
57+
58+
## Priority
59+
<!-- High, Medium, Low -->
60+
61+
## Related Project(s)
62+
<!-- If Yes – e.g. The BB should be used/added in the Eclipse Blueprint A – for demo purposes, show added value,
63+
If No – Project Proposal (e.g. WP4 in FEDERATE, or in the SDV EcoSystem Community Framework -->
64+
SHIFT2SDV
65+
66+
## Availability of Source Code
67+
<!-- Yes / License (e.g. Yes/MIT)
68+
No – Commercial Closed Source -->
69+
70+
## Availability of API
71+
<!-- Yes / License (e.g. Yes/Apache 2.0)
72+
No - Commercial -->
73+
74+
## Type of API
75+
<!-- Web API, Library/Framework API, Operating System API, Database API, Remote API, Hardware API, Other -->
76+
77+
## Potential obstacles
78+
79+
80+
## Maturity Badges
81+
<!-- taken over from Eclipse SDV Process
82+
See Definition of Badges and their Flavors
83+
https://gitlab.eclipse.org/eclipse-wg/sdv-wg/sdv-technical-alignment/sdv-technical-topics/sdv-process/sdv-process-definition/-/wikis/Definition%20of%20Badges%20and%20their%20Flavors
84+
85+
86+
| | Documentation | Requirements | Coding Guidelines | Testing | Release Process |
87+
| --------- |:-------------:|:------------:|:-----------------:|:-------:|:---------------:|
88+
| Gold | Badgelevel | Badgelevel | Badgelevel | Badgelevel | Badgelevel |
89+
| Silver | Badgelevel | Badgelevel | Badgelevel | Badgelevel | Badgelevel |
90+
| Bronze | Badgelevel | Badgelevel | Badgelevel | Badgelevel | Badgelevel |
91+
| No | Badgelevel | Badgelevel | Badgelevel | Badgelevel | Badgelevel |
92+
| NotDefined| Badgelevel | Badgelevel | Badgelevel | Badgelevel | Badgelevel |
93+
94+
Options:
95+
NotDefined/No/Bronze/Silver/Gold
96+
97+
Example:
98+
| | Documentation | Requirements | Coding Guidelines | Testing | Release Process |
99+
| --------- |:-------------:|:------------:|:-----------------:|:-------:|:---------------:|
100+
| Level | [Gold](urlToDoc)| No | Notdefined | Bronze | [Silver](urlToDoc) |
101+
102+
103+
-->
104+
105+
## State (+ date of last change)
106+
107+
<!--
108+
- Incubating (no code yet)
109+
- Implementation started
110+
- First public release available
111+
- Used in production by 1 OEM
112+
- Used in production by >1 OEM
113+
- Abandoned
114+
-->
115+
Implementation started
116+
117+
## System Context
118+
119+
<!--
120+
OS and runtime/framework requirements
121+
122+
eg.
123+
124+
- AGL
125+
- QNX
126+
- ROS-based
127+
- container runtime
128+
- web assembly
129+
- web service
130+
-->
131+
132+
## Bazel compliance status
133+
<!-- The S-CORE project requires all BB contributions to be ready for BAZEL compliant (https://github.com/bazelbuild/bazel)-->

0 commit comments

Comments
 (0)