Implement support for the VEHICLE-INFORMATION-SPEC category
#436
Conversation
`VEHICLE-INFORMATION-SPEC` is used to describe how a given vehicle can be identified in a semi-automatic way. Also, it describes the vehicle's network topology, i.e., how communication with the vehicle's ECUs can be achieved for networking architectures involving gateways. This is described in section 7.3.10 of the ASAM version of the standard. Signed-off-by: Andreas Lauser <[email protected]> Approved-by: Michael Hahn <[email protected]>
Signed-off-by: Andreas Lauser <[email protected]> Approved-by: Michael Hahn <[email protected]>
Signed-off-by: Andreas Lauser <[email protected]> Approved-by: Michael Hahn <[email protected]>
|
|
||
| doc_frags = (OdxDocFragment(doc_name="vehicle_info_test", doc_type=DocType.VEHICLE_INFO_SPEC),) | ||
|
|
||
| vehicle_info_spec_xml_str = """<?xml version="1.0" encoding="UTF-8" standalone="no" ?> |
There was a problem hiding this comment.
Better to move it to its own file
There was a problem hiding this comment.
I'd like to keep the unit tests as self contained as possible. The tests for flashing, variant coding and multiple ecu jobs follow the same pattern..
| vehicle_info_spec_tpl = jinja_env.get_template("vehicle_info_spec.odx-v.xml.jinja2") | ||
| for vehicle_info_spec in database.vehicle_info_specs: | ||
| zf_file_name = f"{vehicle_info_spec.short_name}.odx-v" | ||
| zf_file_cdate = datetime.datetime.now().strftime("%Y-%m-%dT%H:%M:%S") |
There was a problem hiding this comment.
Do you really need to re-create the date each time?
There was a problem hiding this comment.
do you mean the need to call strftime() or the fact that it always uses datetime.now()?
There was a problem hiding this comment.
The line zf_file_cdate = datetime.datetime.now().strftime("%Y-%m-%dT%H:%M:%S") can be moved out of the for loop
There was a problem hiding this comment.
in principle yes, but since the loop body deals with the file in question and this does not come with performance implications, the loop body should handle all properties related to the current file IMO. (also, this makes it easier to handle the dates of individual files if we ever decided to keep track of them...)
|
|
||
|
|
||
| @dataclass(kw_only=True) | ||
| class ModelYear(InfoComponent): |
There was a problem hiding this comment.
This looks wrong, sub-classing InfoComponent each time, without added value
There was a problem hiding this comment.
the added value is that isinstance() can be used to distinguish these objects and thus it is much clearer to ensure that stuff like ECU-CONFIG-REF points to an EcuConfig object. (I thought about using type aliases like the derivatives of ValidityFor, but IMO using a separate class is better for the mentioned reasons and it should be considered to change the ValidityFor family to use separate classes as well.)
we tried to print the enum object which could not be created which means that the snake ate its own tail... thanks to [at]kayoub5 for pointing this out. Signed-off-by: Andreas Lauser <[email protected]>
andlaus
force-pushed
the
vehicle_info_spec
branch
from
d1d12be to
dd9e133
Compare
|
@kayoub5: do you still see any showstoppers here? |
Nothing else from my side |
|
okay, let's merge this then. thanks for your review! |
VEHICLE-INFORMATION-SPECis used to describe how a given vehicle can be identified in a semi-automatic way. Also, it describes the vehicle's network topology, i.e., how communication with the vehicle's ECUs can be achieved for networking architectures involving gateways. This is described in section 7.3.10 of the ASAM version of the standard.Andreas Lauser <[email protected]>, on behalf of MBition GmbH.
Provider Information