Ovomaltine85 commented 7 months ago

This issue is about describing and tracking the steps for creating a minimal viable product (MVP) to showcase the value, functionality, and integration of openDuT for a concrete automotive test case.

Overall goal

To convince users and potential customers of openDuT, we want to create a minimal viable product (MVP) which shows the general functionality of the framework by executing a simplified test scenario.

User story:

As a (potential) user of openDuT I want to verify if openDut (basically) can satisfy my needs of an automotive test framework So that I can test the integration of openDuT into my DevOps, run simple test scenarios and store the test result at a defined place.

Minimum requirements (must have)

[x] openDuT interacts via CAN and ETH with DuTs that are connect to one single peer.
[x] DuTs that are connected to one peer shall be able to communicate with each other via CAN/ETH
[x] The test case (TC) describes in an agnostic language (DSL) the test steps by individual instructions
[ ] Test scenario:
Execute a port scan (eth0) of one DuT by nmap inside a Docker container. The docker image is available locally on the peer.
Execute UDS scan via CAN with CaringCaribou in Docker on another edge client
[ ] The test execution instruction (TEI, JSON)
Use execution mechanism of CARL
Implement management routine for test execution on EDGAR (clean up/ restart container etc.)
[ ] The peer shall perform (test executer) the test scenario based on the TEI
[x] Data storage of test result (log, reports, string etc.) in SMB, WebDAV, FTP or repo push
[ ] openDuT shall provide information and control the DuT:
Measure DuT current/ voltage, potentially bus load
Control: switch power supply on/off via MQTT
Use Grafana / OpenTelemetry for visualization

Additional requirements (may have)

[x] DuTs that are connected to one peer may also interact with other DuTs connected to other peers via CAN and ETH
[ ] Additional test scenario: Execute a python script locally in virtualenv on peer that performs a simple UDS scan
[ ] The framework may provide a (rudimentary) rest bus simulation to keep DuTs in a testable state. Use an ARXML file, parse it and send the signals accordingly on the bus
[ ] openDuT may provide a (simple) GUI that supports the user with creation and edition of a TC
[ ] The docker may be pulled from an external container registry

Time frame

The completion of the MVP (minimum) is projected for mid/end of April'24.

ToDo's

Link tasks above with already existing issues/ stories here in Github
Link PRs to implement the MVP with this issue to keep track of progress

hafklin commented 7 months ago

PRs and issues related to the implementation of CAN functionality:

85 - Add CAN Support

105 - CAN Integration

128 - Allow configuring CAN interfaces via LEA/CLEO

129 - EDGAR -> Use Cannelloni ports provided by CARL

136 - Add configuration to network interfaces