As a developer and user, I want to see the test coverage of the code, so I know that these package is not untested crap.

Use coveralls?
https://coveralls.io/github/mdabrowski1990/uds

Description

As a user, I want to have data container

As a user, I want to have data container for other packets, so I can group packets together (e.g. DTC Number + DTC Status - DTC Status is actually packed of DTC Status bit where each have specific meaning), so I can easily use grouped data.

Important: Packets might sometimes occur varing number of times (e.g. response to 0x1902FF request, might contain from 0 to X packets with DTC Numer + DTC Status).

Testing

• unit tests
  • nested data records
  • big focus on error handling and ambigious cases (multiple records without certain limit)
• integration tests
  • example use cases:
    • response to 19 02 FF request is decoded into DTCs, (DTC Code + DTC Status); DTC Status is also decoded into DTC Status Bits
    • valid response to 19 02 FF is encoded into raw value
    • invalid (missing data) response to 19 02 FF is encoded into raw value

Acceptance Criteria

• I am able to encode values of included Data Records into raw value using Packet Data Record
• I am able to decode raw value into included Data Records using Packet Data Record
• Error handling is implemented.

As a user, I want to see PyPI, Coverage, Pylint, ReadTheDocs status, so I know that this is pofessional work.
As a visitor, I want to who know to contact, so I can become contributor.
As a sponsor, I want to know how I can support the development, so it is top shelf product and compatible with newest ISO Standards.

As a user, I want to have data container with diagnostic service information so I can store and check service information such as supported DIDs/RIDs/Sub-Functions/NRC, request format, response format.

Describe the bug
For some buses (e.g. LIN, or CAN with extended addressing), packet type information is located in the second byte of raw_data.
Function get_raw_packet_type is not always correct, therefore this peace of code requires minor rework.

To Reproduce

1. Go to uds_packet.py
2. Execute get_raw_packet_type for CAN with extended addressing
3. See the result is not correct.

Expected behavior
Value of packet type can only be assessed when bus and its configuration is known (for example CAN with normal or extended addressing have different results)

As a user, I want to have option to quickly checked whether message has correct format (according to database) and decode its signals (data records) according to attached database.
As a user, I want to have option to create messages basing on their signals (data records) values or raw message data.
As a user, I want to have option to dump signal values (either raw or physical values) of any message, so I can check data in human-readable format.

Description

As a user, I want to have data container for data that needs recalculation and might contain units so I can interpret physical values such as speed, acceleration.
As a user, I want to have option to restric a few values to be text, so I can define special values (e.g. 0xFF = 'Failure', 0x00-0xFE: vehicle speed 0-254 km/h).

Testing

• unit tests
  • Value encoding and decoding using Physical Value Data Record
  • Value encoding and decoding when some values are restricted to be Text Values.
  • There is warning raised whenever undefined value is decoded from Text Data Record.
  • There is exception raised whenever undefined value is encoded using Text Data Record.

Acceptance criteria

• I am able to encode text value into raw value using Physical Value Data Record.
• I am able to decode raw value into text using Physical Value Data Record.
• Error handling is implemented.

Requires

#78
#5
#96

Description

As a user, I would like to set all communication parameters on client side, so I can reuse them during communication instead of providing them over and over again.

Client configuration includes:

• DeltaP2request, DeltaP2response, DeltaP6request, DeltaP6response,
  • min value = 0
  • actual value - set by user
• DeltaP2
  • actual value = DeltaP2request + DeltaP2response
• DeltaP6
  • actual value = DeltaP6request + DeltaP6response
• P2server
  • max value = 50ms by default, but can be changed by the user
• P2client
  • min value = P2server_max + DeltaP2
  • actual value - set by user
• P6client
  • min value = P2server_max + DeltaP6
  • actual value - set by user
• P2*client
  • min value = P2*server_max + DeltaP2response
  • actual value - set by user
• P6*client
  • min value = P2*server_max + DeltaP6response
  • actual value - set by user
• P3Client_phys, P3Client_func
  • min value = P2server_max + DeltaP2
  • actual value - set by user

User is unable to set invalid values, e.g.:

• User cannot set any value below 0.
• User cannot set any actual value below min or above max.
• User is warned and actual value is adjusted if user just influenced min/max value and actual value is no longer in range.

Test Strategy

Unit Tests:

• 100% decisions coverage for implemented code

Acceptance Criteria

• It is possible to adjust all Client's parameters that are not constant values, even after the object is created.
• All Client's communication parameters are described in knowledge base.
• User documentation is updated with client configuration examples and explanation.

Description

As a user, I want to have documentation with information about all the features, so I know how to use the package.

Testing:

• review only

Acceptance Criteria:

• All major features (Client simulation, Server simulation, basic UDS messages) are documented with critical (for user) functionalities.
• ReadTheDocs documentation created.
• Github-pages documentation created (if uses the same format as ReadTheDocs otherwise abandon).

Requires

#46

Description

As a user, I would like to have container for diagnostic message data, so I can freely create and modify diagnostic requests and responses.
As a user, I would like to have records for received and transmited diagnostic message data, so I can easily analyse received or transmitted messages.

As a developer, I would like to create separate classes for UDS Message (diagnostic message data - payload, addressing etc.) and UDS Message Record (historic record of transmitted/received message - payload, addressing, transmission time, PDUs, etc.), so they could be distinguished and proper modification restriction (you cannot change historic data) could be implemented.

Acceptance Criteria

• UDS Message class is created and can be imported from uds.messages subpackage
  • UDS Message attributes are mandatory and can be easily modified:
    • payload (raw data)
    • addressing
  • Each argument is validated in constructor and during value change
• UDS Message Records class is created and can be imported from uds.messages subpackage
  • UDS Message Records attributes are mandatory and once set cannot be modified:
    • payload (raw data)
    • addressing
    • pdus
    • transmission time start
    • transmission time end
    • direction (rx/tx)
  • There are no duplicates of data (attributes do not store them) to this contained by PDUs
  • Each argument is validated in constructor and during value change
• there is 100% decisions coverage for new code
• old code is fully removed

Description

As a user, I would like to have defined API of UDS Packets Stack (or other structure), so I can easily use this feature with Transport Interfaces.
As a user, I would like to have common implementation for all packets types (for all buses) or common API defined in Abstract class and implemented in concerete classes for certain buses, so I use it the same way for all bus types and Transport Interfaces.

Example of similar implementation: https://can-isotp.readthedocs.io/en/latest/isotp/implementation.html#isotp.CanStack

Acceptance Criteria

• API for UDS Packet Stack (UdsPacketStack? AbstractUdsPacketStack?) defined:
  • all public methods and properties are annotaded and described (docstrings are created)
  • no code included (except for rasing NotImplementedError or similar)
• UDS Packet Stack design satisfies following restrictions:
  • It is possible to easily find last initiated transmission (single frame or first frame of any type)
  • it is possible to distinguish received and transmitted packets
  • it is possible to await untill incoming/outcoming packet arrives
  • support for multi-threading and asyncio

Describe the bug
Current naming conventions of NPDU is a bit too technical. Why not use packet instead?
Please make it easier to understand for normal people and change the name both in code and in documentation.

As a developer, I want to have abstract TP Interface defined, so I know how to interact with them, event though it is not implemented yet.

Note: They are going to be many different TP Interfaces (at least one for each bus type - it is LIN, CAN, Ethernet, etc.)

Requires

All other issues in this milestone are completed.

Description

As a user, I want to have possibility to install newest version (with new features) of this package straight away from PyPI, so I do not have to do it manually.

Acceptance Criteria

• make sure that package dependencies, authors and other meta data were updated properly according to current state
• tag for new 0.2.0 version is added
• new version is published to PyPI
• release notes are created
• documentation is updated and new version is displayed separately - https://readthedocs.org/projects/uds/versions/

Description

As a user, I would like to have container for PDU data so I can freely create and modify them.
As a user, I would like to have records for received and transmited PDU data so I can easily analyse received or transmitted PDUs.

As a developer, I would like to create separate classes for Abstract PDU (Protocol Data Unit data - payload, addressing, type etc.) and Abstract PDU Record (historic record of transmitted/received PDU - payload, addressing, type, transmission time, etc.) so they could be distinguished and proper modification restriction (you cannot change historic data) could be implemented.
As a developer, I would like to write as much common code in Abstract PDU as possible so I do not have to repeat myself in concrete implementation for certain buses.

Acceptance Criteria

• AbstractPDU class is created and can be imported from uds.messages subpackage
  • PDU attributes are mandatory and can be easily modified:
    • payload
    • addressing
    • type (property which value is determined basing on payload value)
  • Each argument is validated in constructor and during value change
• Abstract PDU Record class is created and can be imported from uds.messages subpackage
  • UDS Message Record attributes are mandatory and once set cannot be modified:
    • frame that carried the PDU
    • payload
    • addressing
    • transmission time
  • There are no duplicates of data (attributes do not store them) to this contained by frames
  • Each argument is validated in constructor and during value change
• there is 100% decisions coverage for new code
• old code is fully removed

As a user, I want to have possibility to export existing databases to text files and import them if needed.

Requires

#85

Description

As a user, I would like to have Transport Interface API defined, so I have interface to use UDS Packets.
As a developer, I would like to have AbstractTransportInterface class with methods (annotated with descriptions) defined, so I know what has to be implemented and what functionalities would be provided in this milestrone.

Acceptance Criteria

• AbstractTransportInterface class is defined
• Each method of AbstractTransportInterface class has annotation and description.
• Transport Interface methods are defined to provide following functionalities:
  • Configuration
    • setting all required parameters at object creation
    • possibility to read all configured parameters
    • timeout values and bus configuration must be stored and accessable by the object
    • only setable parameters can be changed after Transport Interface object is created
  • Transmission:
    • Scheduling transmission of UDS Packets in certain moments of time
  • Receiving:
    • receiving packets when the object is alive
    • receiving is done in the background (async)
  • Storage:
    • storage for all packet that were transmitted
    • storage for all packet that were received

As a user, I want database to be extended with information in which state certain services can be achieved and whether they cause state transition, so I know what is expected response format before sending a message.
As a user, I want response manager to autoamtically create set of rules basing on information provided in database, so I do not need to specify it when these information are already defined in the database.

Requires

#48
#90

Description

As a user, I would like to have Server's API defined, so I know what functionalities are provided by server simulation and how to use them.
As a user, I want to have option to turn the server on/off so I decide when it responds and when it does not.
As a user, I want to have option to configure server with any Transport Protocol interface, so the top level interface is the same regardless of the network and lower layers configuration.
As a user, I would like to have possibility to use ResponseManager, so response messages are automatically created according to a predefined rules set.
As a user, I would like to have possibility to define list of responses to the next messages, so I could force the server to response in a desired way regardless of currently configured rules.
As a developer, I would like to have UDS Server class with methods (with annotations and descriptions) defined, so I know what has to be implemented and what functionalities would be provided by server simulation.

Acceptance Criteria

• Server class is defined.
• Each Server's method has annotation and description. There shall be no code, preferable they raise exceptions.
• Server's methods are defined to provide following functionalities:
  • Setting and reading Server configuration of session parameters (e.g. p2_server) - more details in #91
  • Automatic responding to incoming requests
  • Multiple response messages to one request (for example SID 0x2A and 0x86 responses - periodical or on event)

Description

As a user, I would like to have a chance for private discussion of security relevant topics.
As a developer, I would like to have information where I could have live chat, so I could discuss all kind of development topics, share my screen for pair programmign etc.

Discord server link: https://discord.gg/XYhJGeBg

Acceptance Criteria

• User documentation is udpated with link to discord server.
• Security policy is updated to have information about private discussion on discord.
• ReadMe file is updated
• The server is properly configured:
  • Special area for security relevant topics that cannot be shared publicly
  • Restricted area for development discussions
  • Open area for guests and all kind of topics unrelated to the development

Description

As a user, I would like to have documentation of existing PDU implementation, so I know how to use it and what it is for.
As a user, I would like to have knowledge base of UDS, so I have explanation of UDS terminology and I could understand what is going on even if I am not an UDS expert.

Acceptance Criteria

ReadTheDocs documentation is udpated, sucessfully builds and has following changes:

• PDU implementation is documented:
  • AbstractPCI, AbstractPDU and AbstractPDURecord classes
  • TransmissionDirection and Addressing enums
• New chapter UDS Knowledge Base is created and contains information about:
  • N_PDU
  • N_PCI
  • Addressing

Requires

#78
#79

Description

As a user, I would like to have a feature that shows what UDS Message data carries certain UDS Packet, so I could easily connect UDS Packets into a UDS Message.
As a developer, I would like to have additional property message_payload in both AbstractUdsPacketRecord and AbstractUdsPacketRecord so it was easier to execute and verify segmentation and desegmentation.

Acceptance Criteria

• The only input to __init__ of UdsMessageRecord are packets_records - check uds_message.py
• Changes are updated in User documentation.

Description

As a developer, I would like to separate segmentation duty to separate entity, so I do not have to repeat the code for different Transport Interfaces that handles the same bus.
As a developer, I would like to have common interface for segmentation process for all buses, so I could use it in the same way for all buses.
As a developer, I would like to have possibility to perform segmentation (or reverse operation) of a diagnostic message without transmitting it, so I would be able to make simple verification separate from the rest of the implrementation and reuse it in the code multiple times.

Test Strategy

Unit Tests:

• 100% code coverage for common code for all segmentation classes (if there is any common code)

Acceptance Criteria

• Abstract class for segmentation duty is created.
• Segmentation class provides following functionalities:
  • UDS message is divided into UDS packets according to proper standard (e.g. ISO 15765-2 for CAN) - list of standards.
  • UDS packets are collected in one message.
  • Get number of packets required to build a message after initial frame (SF or FF).
  • Check whether given packet is a valid following packet (CF).
• Concrete classes would be able to handle segmentation for the entire bus (exception: different version of bus might have separate implementation e.g. CAN and CAN-FD).

Description

As a developer, I want to have base DataRecord class (class that is inherited by all DataRecord classes), so I do not need to repeat the code and have common interfaces (methods) for all DataRecord classes.
As a user, I want to have option to define data containers that carries information about format (e.g. number of bytes) and interpretation (e.g. ASCII characters, odmeter) which are meant to help in managing (decode values in) UDS messages.

Testing

• Unit Testing

Acceptance Criteria

• Unit tests have 100% coverage of base DataRecord functionality.
• As a user, I am able to define a simple DataRecord.

Requires

#78
#22
#72

Description

As a user, I want to have an option to send diagnostic request via physical or functional addressing, so I could decide the recipients of the request.
As a user, I would like to receive all the diagnostic responses received to diagnostic request (either physically or functionally addressed), so I could easily communicate with any server.
As a user, I would like to wait till timeout or the first (and the only) response message (to this request) in case of physically addressed request, so I do not waste time as I do not expect more responses.
As a user, I would like to wait till timeout in case of functionally addressed request, so I gather all potential responses as number of receipients (and potential responses) is unknown in this case.

NOTE: This includes support only to the first response to diagnostic request (e.g. in case of request with SID 0x2A or 0x86). The client shall detect whether the response message (either by RSID or SID data prameter in case of negative response message) relates to the transmited message.

Test Strategy

Unit Tests:

• 100% code coverage

Integration Tests:

• GIVEN Client is configured, WHEN I send a simple request and responses to other requests are received, THEN responses to other requests are filtered out and not returned to the user (regardless if this is an error case or not).
• GIVEN Client is configured, WHEN I send a simple request via physical addressing and response is received THEN the response is immediately returned to the user.
• GIVEN Client is configured, WHEN I send a simple request via physical addressing and no response THEN the method is executed till timeout and error is raised.
• GIVEN Client is configured, WHEN I send a simple request via functional addressing and responses are received THEN the all the responses are returned to the user after the timeout occurs.
• GIVEN Client is configured, WHEN I send a simple request via functional addressing and no responses are received THEN nothing is returned to the user when the timeout occurs.

System Tests:

• GIVEN Client is configured with real CAN bus, WHEN I send a simple request (e.g. DiagnosticSessionControl, TesterPresent or unsupported request) via physical addressing, THEN the received response are returned to the user.
• GIVEN Client is configured with real CAN bus, WHEN I send a simple request (e.g. DiagnosticSessionControl, TesterPresent) via functional addressing, THEN all the responses is received are returned to the user.
• GIVEN Client is configured with real CAN bus, WHEN I send a unsupported request via functional addressing, THEN no response is returned to the user.

Acceptance Criteria

• Client code is updates and provides all described functionalities
• Documentation of this feature is available for the user in ReadTheDocs
• 100% test coverage for provided functionalities
• system tests on CAN are prepared, executed and passsing

As a user, I want to have TP Interface for Ethernet, so I can configure Ethernet bus and use UDS package to communicate over Ethernet using UDS protocol.

As a user, I want to have an option to attach messaging database to response manager, so the server responds automatically according to the database content.
As a user, I want to have a feature to set data record values in responses, so I can decide exactly what the response would be.
As a user, I want the resposne manager to use default values for data records if I do not provide one, so I do not have to worry when I do not know what to set.

Requires

#78
#75
#77
#96

Description

As a user, I would like to segment UDS message into CAN packets, so I could use CAN packets without transmitting them.
As a user, I would like to have support for very long messages (over 4095 bytes), so I could handle long messages with this package as well.
As a user, I would like to have support for both classic CAN and CAN-FD, so I can work with all CAN types.
As a user, I would like to have support for all kind of CAN addressings (including Normal and Extended), so I do not limit myself when using this package.

Test Strategy

Unit tests:

• 100% code coverage for the provided code

Integration tests:

• Single Frame segmentation and desegmentation:
  • GIVEN UDS Message that fit into one packet, WHEN the message is segmented into UDS packets by CAN segmenter, THEN one CAN packet is received.
  • GIVEN CAN packet (the same as the output from the previous procedure), WHEN the packet is collected into UDS Message, THEN UDS Message is received (the same as the as input to the previous procedure).
• First Frame and Consecutive Frame segmentation and desegmentation:
  • GIVEN UDS Message that does not fit into one packet, WHEN the message is segmented into UDS packets by CAN segmenter, THEN multiple CAN packets are received.
  • GIVEN CAN packets (the same as the output from the previous procedure), WHEN the packets are collected into UDS Message, THEN UDS Message is received (the same as the as input to the previous procedure).
• Errors
  • GIVEN UDS packets set with missing or unmatching packet, WHEN the packets are collected into UDS Message, THEN error is raised with proper explanation.
  • GIVEN UDS packet that is not single frame, WHEN the packets are collected into UDS Message, THEN error is raised with proper explanation.
  • GIVEN UDS packet that is single frame with SF_DL value greater than carried in the frame, WHEN the packets are collected into UDS Message, THEN error is raised with proper explanation.

Acceptance Criteria

• CAN segmentation feature is fully provided for the user, tested and documented (in user documentation - separate chapter?)
• CAN segmentetion handles all types of CAN configurations:
  • both CLASSIC CAN and CAN FD are supported
  • all addressing types are supported (Normal, Extended, Mixed, etc.)
• Knowledge base documentation is updated with CAN segmentation process explanation and examples

Requires

#48

Description

As a user, I would like to have Client's API defined, so I know how to execute certain actions using this package.
As a developer, I would like to have UDS Client class with methods (with annotations and descriptions) defined, so I know what has to be implemented and what functionalities would be provided by client simulation.

Acceptance criteria

• Client class is defined.
• Each Client's method has annotations and description. There shall be no code, preferable it raises exception.
• Client's methods are defined to provide following functionalities:
  • Setting and reading Client configuration (client parameters e.g. p2_client) - more details in #72
  • Sending diagnostic request and receiving all response(s) to this request (only the first one if cyclical/on event responses are expected).
  • Starting cyclical sending of TesterPresent frames.
  • Stopping cyclical sending of TesterPresent frames.
  • Getting multiple responses that are transmitted periodically or on event (e.g. SID 0x2A or 0x86).

Description

As a user, I would like to have API of this package fully documented, so I could easily find all important information in the documentation without need to get through the code.

Consider https://sphinx-autoapi.readthedocs.io/en/latest/index.html

Acceptance Criteria

• User API is fully documented in User Documentation

Description

As a user, I want to have possibility to install this package straight away from PyPI, so I do not need to clone the repo, manually install dependencies etc.

Reserve a reasonable name (uds and python-uds are reserved, refer to https://pypi.org/search/?q=uds ) for the package.
Use testing server first, so you do not screw anything up

Acceptance criteria

• tag first release according to SemVer
• first version is published on PyPi
  • get rid of unused code
  • follow publishing the package tutorial
  • it is possible to install the package using pip install [package-name] command
• ReadTheDocs updated:
  • new version is displayed separately - https://readthedocs.org/projects/uds/versions/
  • installation chapter is updated
• status badge is added to the main page - please refer to https://codeinthehole.com/tips/pypi-readme-badges/
• link to PyPi in wiki is updated
• add tidelift link to funding.yml and update current ways of sponsoring the project
• update current project status of CII Best Practices

Description

As a user, I would like to have UDS OSI Model documented, so I know which ISO (or other) standards describes certain UDS functionalities, but also which subpackages/classes/methods handlkes them in the code.

Acceptance Criteria

• UDS knowledge base is updated with:
  • UDS OSI Model
  • standards that describes certain functionalities
  • currently implemented functionalities
  • milestones dureing which certain functionalities are planned / will be implemented

Describe the bug
AbstractNPCI class inherits after ByteEnum while it is only 4 bits long

To Reproduce

from use.messages import AbstractNPCI

# expects errors, but it is accepted:
AbstractNPCI.add_member("new_member_1", 128)
AbstractNPCI.add_member("new_member_2", 255)

Expected behavior
AbstractNPCI shall always be 4 bytes (1 nibble), so value shall be in range 0-127.

Requires

#5

Description

As a user, I would like to have an option to start or stop cyclical sending of TesterPresent frames, so I could decide whether to upkeep diagnostic current state of the ECU.

Acceptance Criteria

• Given cyclical TesterPresent sending is on, when I send a diagnostic request, then I get only responses to the diagnostic request.
• Given cyclical TesterPresent sending is on, when I send a diagnostic request, then TesterPresent would be rescheduled to not interrupt transmission of the diagnsotic request.
• Documentation of this feature is available for the user in ReadTheDocs

Description

As a user, I would like to have functionality of internal server state, so I would be able to simulate complex server ECUs that act the same way as the real one.
As a developer, I would like to have AbstractServerState (or similar) class defined (with its API), so I know the methods and attributes that would be implemented.

Desired state functionalities must be taked into consideration:

• state has predefined list of possible values that it might take
• there is exactly one state value at the moment
• states might depend on each other (change of State1 value might result in change of State2 value), therefore - observer would probably be required
• the state object always stores the actual value (the value is not determined upon a call, but updated without any user interaction)

Acceptance Criteria

• API of Abstract Server State class is defined
• there is no (or little code) - preferably only exceptions (e.g. NotImplemntedError) are raised
• all required functionalities are satisfied by the designed API

Description

As a user, I would like to have number of downloads presented in the ReadMe file, so I know how popular this package is.
As a user, I would like to have supported versions of python presented in the ReadMe file, so I know which version of python I need to use this package.
As a user, I would like to have all badges grouped (thematically ), so increase the readability.

This portal provides personalized badges with this feature.

Consider additional badges, e.g.:

• https://github.com/Naereen/badges#pypi-downloads (number of downloads)
• https://github.com/Naereen/badges#pypi-python-versions
• https://github.com/Naereen/badges#pypi-status
• https://github.com/Naereen/badges#discord (currently online)

Acceptance Criteria

• ReadMe contains total number of downloads that this package had
• badges are grouped thematically

Requires

#48
#143

Description

As a user, I would like to have efficient way of configuring Transport Interface with python-can bus, so I do not repeat parameter that are already configured for the CAN bus.
As a user, I would like to have possibility to set all CAN specific UDS parameters, so I could consciously configure my CAN Transport Interface.

Mandatory UDS parameters to configure:

• CAN addressing information (addressing format, target address, source address, address extension and CAN ID) for physical and functional addressing
  

Optional UDS paramaters to configure:

• CAN DLC of outcoming frames
  
• CAN Frame Data Optimization
• Block Size used in Flow Control
• Separation Time minimum used in Flow Control
• timing (and timeout) values - chapter 9.8 in ISO 15765-2
  • N_As
    • timeout = 1000 ms
  • N_Ar
    • timeout = 1000 ms
  • N_Bs
    • timeout = 1000 ms
  • N_Br
    • performance N_Br + N_Ar < 0.9N_Bs timeout
  • N_Cs
    • performance N_Cs + N_As < 0.9N_Cr timeout
  • N_Cr
    • timeout = 1000 ms

Test Strategy

Unit Tests:

• 100% code coverage

Acceptance Criteria

• All described parameters can be configured (either directly or via python-can Bus) in Transport Interface for python-can.
• All described parameters values are accessable for reading.

Description

As a user I want to have restrictions to ByteEnum values so I cannot set incorrect or already used value.

Relates to:

• RequestSID
• ResponseSID
• NRC

Testing approach:

• unit tests:
  • boundary values analysis
  • try to register member on definition and after running the program

Acceptance Criteria:

• Members can be created on definition and after the program start for all these Enums
• Member with incorrect value (out of range, wrong type) cannot be created for any of these Enums
• Duplicate member (with the same value) cannot be created for any of these Enums

Description

As a developoer, I would like to have automatic security scans configured, so I do not have to do it manually.
As a user, I would like to see current status of security scans against this package, so I know I won't be hacked after installing/using this software.

Acceptance Criteria

• Automatic security scans are performed regularly (either daily or weekly) during the night (between 23:00-6:00 GMT+2).
• Badge with security scan result is shown in README.rst file.
• CII Best Practices status is updated accordingly.
• All issues found by initial scan are reported as bugs (or here https://github.com/mdabrowski1990/uds/security/advisories)

Implement UDS Request and Response

As a user, I want to have an option to create UDS Request and UDS Response objects so I can easily create and interpret messages.
As a developer, I want to have UDS Message class which contains common implementation for Request and Response, so I do not have to implement and test features twice.
As a user, I want to have timestamp when the message was received (wither by server or client), so I can check it.
As a user, I want to have option to check response type (positive, negative, invalid in terms of protocol), so I do not have to implement it myself.
As a user, I want to have easy access to raw message data, so I can modify however I please. Note: once modified, some other fields might also be changed (e.g. time of frame reception shall be reset).

Description

As a user, I would like to have a chance to use new features from direct installation from PyPI, si I do not have to copy all the code by myself.

Acceptance Criteria

• tag for new version is added
• release notes are created
• new version is published to PyPI
• ReadTheDocs displays this and previous version: https://readthedocs.org/projects/uds/versions/

Requires

#78
#79
#96

Description

As a user, I would like to have dedicated UDS Packet implementation for CAN, so I could easily communicate using CAN bus.
As a user, I would like CAN Packet and CAN Packet Record classes have support for python-can frames, so I could easily use python-can with this package.
As a user, I would like to have UDS Packet and UDS Packet Record implementations supporting all possible CAN addressings (Normal, Extended, Mixed, etc.) and bus types (CLASSIC CAN and CAN-FD), so I could use it in all possible situations.
As a developer, I would like to have CAN Packet classes that inherits after AbstractUdsPacket class, so I have CAN packet implementation separated.
As a developer, I would like to have CAN Packet Record classes that inherits after AbstractUdsPacketRecord class, so I have CAN packet record implementation separated.
As a developer, I would like to have flexible implementation of CAN Packet Record, so it supports python-can frame but it is also extendable and could provide support for other CAN libraries that could be used in the future.

Test Strategy

Unit Tests:

• 100% code coverage for CAN Packets specific code

Integration Tests:

• GIVEN python-can frame that carries diagnostic message, WHEN I provide this frame to CAN Packet Record, THEN I can create CAN Packet Record object and read all relevant information from it.
• GIVEN python-can frame that obviously carries non diagnostic message, WHEN I provide this frame to CAN Packet Record, THEN and error is raised.

Acceptance Criteria

• UDS Packet and UDS Packet Record for CAN bus are Integrated with python-can frame
• UDS Packet and UDS Packet Record supports all CAN configurations:
  • all bus types (CLASSIC CAN and CAN-FD)
  • all addressings types (including Normal, Fixed, Mixed)
• User Documentation is updated:
  • UDS Packet Definition for CAN is documented
  • UDS Packet Record for CAN is documented
  • UDS Packet Type for CAN is documented
• CAN Packets and their types are described in knowledge base.

As a user, I want to have certain container for raw data that has no special interpretation (e.g. unrelevant reserved value, or simply a number something).

Description

As a developer, I would like to have diagrams with data flow (frames, N_PDUs, Diagnostic Services) created, so I could better understand the implementation.
As a user, I would like to have documentation about data flow, so I could understad where to look for the information I need (also in the code).

Acceptance Criteria

ReadTheDocs documentation is updated:

• diagrams with relationship between UDS message, N_PDU, bus frame in the code are added
• description of the segmentation (from the ISO standards perspective) is added

Diagrams are added to docs, preferable created using draw.io.

As a user, I want to have TP Interface for LIN, so I can configure LIN bus and use UDS package to communicate over LIN using UDS protocol.

Requires

#73
#144

Description

As a user, I would like to have possibility to schedule CAN Packet transmission at provided time, so I can control how packets are transmitted.
As a user, I would like to have container that automatically detect received CAN packets and store them, so I have access to entire UDS communication.
As a user, I would like to have possibility to use python-can library, so I do not have to buy any expensive tools.

Testing Strategy

Integration Tests:

• receiving packets is possible (mock the incoming traffic)
• transmitting packets is possible (mock the transmission monitoring)

System Tests:

• GIVEN configured Transport Interface with python-can, WHEN I schedule CAN Packet transmission, THEN it is transmitted to the bus at the first timeslot after the scheduled time is reached, and record of transmitted packet is stored with proper timestamp.
• GIVEN configured Transport Interface with python-can, WHEN UDS CAN packet is received, THEN record of the received packet is stored with proper timestamp.
• GIVEN configured Transprort Interface with python-can, WHEN CAN frame that is not UDS Packet is received, THEN it is not stored by the Transport Interface.
• GIVEN configured Transport Interface with python-can, WHEN python-can bus is used to transmit other frames, THEN it is not blocked by this package.
• GIVEN configured Transport Interface with python-can, WHEN python-can bus is used to receive frames, THEN it is not blocked by this package, neither the package is malfunctioning.

Acceptance Criteria

• described features are provided
• Provided features are document in user documentation
• 100% code coverage for this change
• system tests are executed and passing (preferably automatic, but it can be manual if impossible to automate).

Description

As a user, I want to have data container for data with text interpretation (e.g. 0 -> 'off', 1 -> 'on'), so I can either use text (or raw value) to set value in this data record.

Testing

• unit tests
  • Value encoding and decoding using Text Data Record
  • There is warning raised whenever undefined value is decoded from Text Data Record.
  • There is exception raised whenever undefined value is encoded using Text Data Record.

Acceptance criteria

• I am able to encode text value into raw value using Text Data Record.
• I am able to decode raw value into text using Text Data Record.
• Error handling is implemented.

Describe the bug
Methods is_request_sid and is_response_sid of RequestSID and ResponseSID enums are returning False when unknown (unsupported) value is provided even if this is legit SID value.

To Reproduce
Steps to reproduce the behavior:

from uds.messages import RequestSID, ResponseSID

assert RequestSID.is_request_sid(0x01) is True
assert ResponseSID.is_response_sid(0x41) is True

Expected behavior
Expect True returned in both cases (as in assertions), False is returned instead.

Requires

#47

Description

As a user, I would like to have documentation of existing UDS Message implementation, so I know how to use it and what it is for.
As a user, I would like to have explanations of UDS terminology related to UDS Messages, so I could understand what is going on even if I am not an UDS expert.

Acceptance Criteria

ReadTheDocs documentation is udpated, sucessfully builds and has following changes:

• UDS Message implementation is documented:
  • UDSMessage, UDSMessageRecord classes
  • RequestSID, ResponseSID and NRC enums
  • All functions and classes of messages.py that might be directly called by a user.
• UDS Knowledge Base is updated and information about following topics are added:
  • basic UDS communication assumptions (e.g. request initiates transmission, one message at the time)
  • UDS Request
  • UDS Response - responses types and formats (e.g. NRC)
  • Service Identifiers - list of services defined by ISO14229 and their use cases

Requires

#5

Description

As a user, I would like to have possibility to receive cyclically (or on event) sent responses (e.g. to request with SID 0x2A), so I am able to use this feature without workarounds.

Acceptance Criteria

• Given diagnostic request with cyclical (or on event) response is sent, When I request the response, Then I receive responses that were received till this moment.
• Given diagnostic request with cyclical (or on event) response is sent, When I send another request, Then I will receive response to the request that I jsut sent.
• Documentation of this feature is available for the user in ReadTheDocs