diff --git a/feeder/feeder-evic/README.md b/feeder/feeder-evic/README.md index 579266f5..f73f980c 100644 --- a/feeder/feeder-evic/README.md +++ b/feeder/feeder-evic/README.md @@ -1,6 +1,6 @@ # External Vehicle Interface Client Feeder The EVIC feeder enables the Vehicle Interface client to be implemented as a separate process that is communicating with the feeder over a Websocket protocol, see the figure below. -![EVIC feeder tech stack](pics/VISSv2-tech-stack-EVIC-feeder.jpg?pct=50)
+![EVIC feeder tech stack](/pics/VISSv2-tech-stack-EVIC-feeder.jpg?pct=50)
A scenario where this could be of interest is if an implementation of an interface client exists, written in another language than the language of the feeder, which is the Go language. This was the case when it was developed, a CAN driver interface was available in Python, which then was extened with the Websocket interface to the EVIC feeder. diff --git a/feeder/feeder-evic/evicSim/README.md b/feeder/feeder-evic/evicSim/README.md index 1d7b1069..59d30577 100644 --- a/feeder/feeder-evic/evicSim/README.md +++ b/feeder/feeder-evic/evicSim/README.md @@ -1,4 +1,4 @@ -#External Vehicle Interface Client Simulator +# External Vehicle Interface Client Simulator This simulator is mainly meant to be used to verify that communication can be established with the EVIC feeder. It is hardcoded to simulate the signals defined in the variable canSignals, which are the set of signals defined in the WAII/tools/DomainConversionTool/CAN-v0.1.yaml file. To use it with other Vehicle domain signals, the array elements of this variable has to be changed before building the simulator. diff --git a/tools/DomainConversionTool/README.md b/tools/DomainConversionTool/README.md index b498a90e..094f9057 100644 --- a/tools/DomainConversionTool/README.md +++ b/tools/DomainConversionTool/README.md @@ -11,7 +11,7 @@ The description must use the syntax as specified by VSS. It can contain a comple Before the signal descriptions there must be a line giving the name of the domain:
Domain: name-of-domain
An example of a southbound domain description is shown in the figure below. -![Southbound domain signal definitions](pics/Southbound-domain-signals.png?pct=75)
+![Southbound domain signal definitions](/pics/Southbound-domain-signals.png?pct=75)
The mapping file must first define the names of the northbound and southbound domains, respecively:
NorthBoundDomain: name-of domain
SouthBoundDomain: name-of domain
@@ -21,8 +21,8 @@ Mapping:
South: signal-name
- North: signal-name
South: signal-name
-An example of a mapping file is shown below. -![Signal mapping example](pics/Signal-mapping.png?pct=75)
+An example of a mapping file is shown below.
+![Signal mapping example](/pics/Signal-mapping.png?pct=75)
The DCT directory contains three signal description files:
* CAN-v0.1.yaml // A southbound domain example describing 5 CAN signals * VSS-v0.1.yaml // A northbound domain example describing 6 VSS signals @@ -31,6 +31,10 @@ The DCT directory contains three signal description files:
The directory also contain a mapping file example for mapping signals from the CAN-v0.1 domain with signals from the VSS-v0.1 domain. * MAP-VSSv0.1-CANv0.1.yaml +For scaling due to different units representing the data of the two domains the DCT reads a file containing linear scaling coefficients. +This file can be augmented with more unit scalings than its current examples. +* UnitScaling.yaml + DCT provides the following operations, that are selected by adding a command parameter to the DCT start command. * domains // displays the domains that have been imported by the tool, i. e. that are stored in tables of the tool database. * datamodel // displays the domains that have been imported by the tool, i. e. that are stored in tables of the tool database. @@ -78,14 +82,16 @@ The other two files that were generated by the DCT are stored in the directory o or else the files can be renamd to the names tht the feeder tries to read per default, "VssVehicle.cvt" and VssVehicleScaling.json". ## DCT limitations -This first verion of the DCT has some known limitations that are expected to be mitigated in later versions. +This first version of the DCT has some known limitations that are expected to be mitigated in later versions. * Arrays in the YAML input files cannot use the syntax [elem1, .., elemN] but must be represented as - - elem1
- ..
- - elemN
+``` + - elem1 + .. + - elemN +``` * Signals from respective domains with number datatypes must have the same datatype, i.e. a uint8 in the northbound domain can only be mapped to a uint8 in the southbound domain. * Signals with allowed data restrictions must be defined with its elements in the same order in both domains, and with the same number of elements. - * Booleans must on the southbound side be represented by ["0", "1"] as the logical values [false, true]. + * Booleans must on the southbound side be represented by the string values "0" or "1" as the logical values false or true. * The unit scaling is limited to the definitions in the UniScaling.yaml file. As an example, if the first defined element in one domain logically represents OFF then th first element in the other domain must also logically represent OFF. * It is not possible to delete either single data point entries in a domain, nor entire domains. This can of course be done by using some other SQLite tool capable of it. diff --git a/tutorial/content/build-system/_index.md b/tutorial/content/build-system/_index.md index e6c8ad20..49ac8303 100644 --- a/tutorial/content/build-system/_index.md +++ b/tutorial/content/build-system/_index.md @@ -45,6 +45,10 @@ After the refactoring of these SwCs into one process with ech actor running as a it became more convenient to build without this script, but it is still [avaliable](https://github.com/w3c/automotive-viss2/blob/master/W3CServer.sh). For more details, see the "Multi-process vs single-process server implementation" chapter in the README. +There are multiple Software components on this repo, such as feeders, simulators, the DCT tool that are to be built as separate excutables. +If it is forgotten to be mentiond in the README, one way of determining whether a separate build is needed or not is to check the package statement in the source code. +If it says "package main" it is a separate executable and shall then be built and run as described above. + ### Loggging Logging can be command line configured at startup. * logging level can be set to either of [trace, debug, info, warn, error, fatal, panic]. diff --git a/tutorial/content/server/Access-control-servers/_index.md b/tutorial/content/server/Access-control-servers/_index.md index 3e75981a..aa156f7d 100644 --- a/tutorial/content/server/Access-control-servers/_index.md +++ b/tutorial/content/server/Access-control-servers/_index.md @@ -143,7 +143,7 @@ Error response: {“action”: “agt-request”, "error":"error-reason"} // if AT request: {“action”: “at-request”, "agToken":"x.y.z", "purpose":"purpose-description", "pop":""} // pop shall be an empty string for access control short term flow. AT response 1: {“action”: “at-request”, "aToken":"x.y.z"} ATS->Client // Consent is not required. -. + AT response 2: {“action”: “at-request”, "sessionId ":"reference-Id", “consent”:”NOT_SET”} // Consent is required, and consent reply not obtained yet from ECF. AT inquiry request: {“action”: “at-inquiry”, "sessionId":"reference-Id"} // may need to be issued multiple times until consent is provided by ECF.