The DaVinci Transform provides an interface between the MxSuite and the Vector DaVinci Component Tester. The diagram below illustrates the data flow from MxVDev TestCases to the Software Component SUT.
• DaVinci Component Tester installed and licensed.
• MxSuite Version 184.108.40.206815 or greater.
1.Ensure that the DVACTBIN environment variable is set properly for the compiler being used (per the DVACT documentation). This is the only environment variable that is required to be set for MxVDev to use the DaVinci Transform, as this is the location that any dependency DLLs are searched at run time.
...\net-2.0 for Visual Studio 2008
...\net-4.0 for Visual Studio 2010
2.Ensure that the DVACTBUILD is set properly for the tools being used to generate the SWC as described in the DVACT documentation.
3.Ensure the DVACTINCLUDE environment is set properly (per the DVACT documentation.
4.Build the Software Component as described in the DVACT documentation for NUnit testing. Take note of the following parameters that are passed to the SUTInfoGenerator tool, as they are required to be set as properties in the DaVinci transform:
•--OUTDIR: The location where the SWC DLL and the Test API DLL will be located. This path is required to find the DLL for harness and runtime.
Set the Location property of the Transform to this value.
•--SUTEXE: While this can be anything, it currently must be set to the same name as the --SWC parameter that is passed to the ContractGenerator tool. This is because this property in MxV is used both as the SUT DLL to load, and also as the type name to search for in the SUTInfo DLL.
At this time, the --SUTEXE parameter for the SUTGeneratorApp (args.txt) must match the --SWC parameter for the ContractPhaseGeneratorApp (cpgargs.txt). This name is being used to both search for the SUT in the TestAPI DLL and also as the base name for the SUT component DLL to be loaded.
These limitations will be lifted in future builds. Set the Root Component Name property to this value.
•--SUTINFO: The file name (no extension) of the DLL that contains information about the Testing API. Set the Test API Name property of the Transform to this value. This is the info DLL that is built.
5.Start MxTransIt, and add the DaVinci Transform to the harness.
6.Set the properties as described above.
7.Activate the verb "Re-Attach to Model". This scans the TestAPI DLL for ports and data types.
8.Click on the button for the Initialization Runnables, and move the initialization runnables from the left to the right. These runnables are triggered during module reset and the arming of the transform.
The order they appear in the list is the order that they will be triggered at runtime.
9.Click the button for the Runtime Runnables, and move the runnables from the left to the right. The order they appear in the list is the order that they will be triggered during each tick.
10.Set the transform tick time. This should be the same as the fundamental sample period for the model. See limitation note below.
11.Run the test cases.
For an MxV Module Reset to reset the Dwork variables, UNCHECK Simulation->Configuration Parameters->Optimization->Remove internal data zero initialization and also Optimize initialization code for model reference. This way, the Init runnable is populated with state initialization variables.
In addition, Stateflow charts must ensure that the property "Execute (enter) chart at Initialization" is set to generate code for the initialization function. This code is run at scenario start, and also when an MxV Module Reset is sent. If the property is not set, the MxV Module Reset will not initialize the state machine to its initial state, and subsequent runs proceed as if the state machine remained in the last state from the previous run.
The reason that this behavior differs from the S-Function co-simulation is that during module reset of the S-Function, the model is actually restarted via Simulink, whereas the generated AUTOSAR code is not subject to this as it is standalone.
The DaVinci Transform is a Connector Transform. By default, a Delay Transform is required to connect with another Connector Transform. However, if the Treat as SUT property is set to False, the Delay is not required.
1.Simulink (at least in version 2011b) emits incorrect limits in the arxml files for REAL-TYPE DataTypes.
SWCs that use these data types generated from Simulink must manually edit the data type definitions.
2.Stateflow charts must ensure that the property "Execute (enter) chart at Initialization" is set to generate code for the initialization function. This code is run at scenario start, and also when an MxV Module Reset is sent.
If the property is not set, the MxV Module Reset will not initialize the state machine to its initial state, and subsequent runs will proceed as if the state machine remained in the last state from the previous run.
3.Enumeration types exported are not named properly when imported into the MxVDev signal dictionary.
4.CALPRM types (both internal and on a port definition) are not currently supported.
5.Record types (such as Bus Ports) are not supported.
6.Only Atomic software components (non-composite) are supported. This means that only one module may be tested at a time in MxVDev. This is more due to the fact that DaVinci only supports loading one system at any one time in the executable's working space. Basically, at this time, only unit-tested individual AUTOSAR SWCs are supported. This limitation may be lifted in the future. In addition, only Port interfaces with a single DataElementPrototype are currently supported.
7.Each runnable in the software component is currently ticked at the same rate, multiple rate runnables are currently not supported. In addition, port based events on top level runnables are not currently supported, only timing events.
In addition, the user must manually set the tick period, as there is currently no exposure to the event types generated by the DaVinci software.
8.The software component must be generated prior to loading it from the transform, there is currently no mechanism to compile the SWC from MxTransIt/MxVDev.
9.Due to limitations of the .NET runtime when loading assemblies into the default AppDomain, once the DaVinci generated DLLs are loaded, they cannot be unloaded. Therefore, if MxTransIt or MxVDev has loaded a transform with the DaVinci DLL, any changes to the SWC DLLs will not occur until MxVDev/MxTransIt is restarted.
10.Re-harnessing a component loses any set values for Runnables. In addition, there is no warning/error if there are runnables that are discovered but that do not exist in either the Initialization or Runtime Runnables property.
11.Spurious XML parse errors may be emitted in the notifications window during harness load. These errors may be safely ignored.
12.When DaVinci compiles, by default it uses the Debug version of the CRT provided by the compiler, which is not distributable. These are not installed on a system that does not have Visual Studio installed, as these libraries are non-distributable (as specified by Microsoft). Therefore, to compile these modules you must do one of the following:
•Copy the debug libraries from the system used to build to the system that has the component. These files are located at
\Program Files (x86)\<Microsoft Visual Studio Version used to compile davinci>\VC\redist\Debug_NonRedist\x86\Microsoft.VCXX.CRT\*.dll
•Run MxVDev on the system that was used to compile the DaVinci component