This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Component Implementation

1: MotCtrlMgr Integration Manual
2: MotCtrlMgr Review
3: MotCtrlMgr_MDD
4: MotCtrlMgr DataDictionary Tool User Guide

Component Implementation

Component Documentation

Specific Component Tools

MotCtrlMgr DataDictionary Tool User Guide.html

1 - MotCtrlMgr Integration Manual

Integration Manual

For

MotCtrlMgr

VERSION: 3

DATE: 09/21/16

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA

Location: The official version of this document is stored in the Nexteer Configuration Management System.

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial version	Lucas Wendling	1	05/29/15
2	Updates for Signal Mapping	Lucas Wendling	2	10/28/15
3	Updates describing tool that generates MotCtrlMgr configuration	Lucas Wendling	3	09/21/16

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

3.2 Global Functions(Non RTE) to be provided to Integration Project 6

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
	<ADD more to the table if applicable>

References

This section lists the title & version of all the documents that are referred for development of this document

Sr. No.	Title	Version
1	MDD Guidelines	Process 04.00.00
2	Software Naming Conventions	Process 04.00.00
3	Software Coding Standards	Process 04.00.00
4	AR300A_MotCtrlMgr_Design	See Synergy subproject version

Dependencies

SWCs

Module	Required Feature

Note : Referencing the external components should be avoided in most cases. Only in unavoidable circumstance external components should be referred. Developer should track the references.

Global Functions(Non RTE) to be provided to Integration Project

MotCtrlMgrIrq – This is a category 1 interrupt (see details below)

Configuration REQUIREMeNTS

In addition to configuration based .c and .h files, the MotCtrlMgr generator will also generate a .m file data dictionary for MotCtrlMgr. In addition to documentation purposes, this data dictionary is intended to aid in the creation of the AUTOSAR SWC model that is required to be created for the MotCtrlMgr’s signal interface to the RTE. While the generator will create the RTE runnables and runnable contents automatically, the SWC model to be used in the AUTOSAR authoring tools (e.g. Davinci Developer) is not automatically created by the generator and will need either a separate tool to create, or will need to be manually created.

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

CDD_MotCtrlMgr.c

CDD_MotCtrlMgr_Data.c

CDD_MotCtrlMgr_Data.h

CDD_MotCtrlMgr_Irq.c

DaVinci Parameter Configuration Changes

Most of the configuration parameters in the table below are determined from extracted data from the component data dictionaries of a given project. This includes all of the motor control related runnables as well as all of the signals that interface to motor control related runnables (on either sender or receiver side).

The DataDictionary tool has been updated to support generation of the majority of the MotCtrlMgr configuration listed below. The inputs this tool requires is a project’s collection of component DataDictionaries, a signal mapping xml, as well as the latest FDD tool data management folder. The DataDictionary tool currently generates a .arxml file with all of the MotCtrlMgr configuration except the following parameters which still need to be manually populated:

/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/IncludeHeaders

/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/Runnable/SequenceOrder

The DataDictionary tool version which was used for testing of this component is embedded within this component’s baseline. This particular version of the tool is included mostly for reference purposes, and isn’t required to be used at an integration level for the actual generation of the MotCtrlMgr configuration so long as the version that is being used produces the correct output.

Parameter	Notes	SWC
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/IncludeHeaders	All of the includes that are required to provide runnable prototypes (e.g. “MyHeader.h”)	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/Runnable	All of the runnables that are required in a given project that run at the “MotorControl” or “MotorControlx2” Rate. The shortname needs to exactly match the runnable function name	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/Runnable/RunnableRate	Selection of the rate at which the given runnable executes (MotorControl or MotorControlx2)	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/Runnable/SequenceOrder	Sequence order number to help define the ordering of the runnables relative to each other. Lower numbers are executed prior to higher numbers. Ordering does not need to be sequential, but it is recommended for clarity. Please note that if all MotorControlx2 runnables are not grouped together, there will be throughput inefficiencies.	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/IncludeHeaders	All of the includes that may be required to provide signal initial values (e.g. “MyHeader.h”). This is possibly required if initial values are required to be tied to a global constant that is defined in a certain header for example.	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum	All of the enumeration definitions required outside of the RTE. The short name needs to exactly match the desired enumeration name.	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum/EnumImplementationDataType	Implementation Data Type of the given enumeration. Selection of the supported types of “uint8”, “uint16”, and “uint32”.	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum/EnumElement	Elements of a given enumeration. The short name should be the enumeration element name.	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum/EnumElement/Value	Numeric value of a given enumeration element	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/SignalMapping	Contains the configuration required for mapping differently named signals to eachother. This component specifically requires, at a minimum, all of the mapping of names related to signals that flow into, out of, or through the Motor Control runnables. Recommended “Short Name” of container is “<OutputSignal>Map”	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/SignalMapping/OutputSignalName	Output signal name of signal needing mapping	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/SignalMapping/InputSignalName	Input signal name (or names) of signal needing mapping. Note that it is allowed to map more than one input name to each output.	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal	Contains the required details of a given signal. The short name should match the base signal name (excluding “MotCtrl” prefix)	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/EnumerationNameReference	Selection of Enumeration (if applicable - this should only exist on signals that are enumerations). Enumeration needs to be added to “/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum” configuration before it can be selected.	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ImplementationDataType	Selection of Implementation Data Type of signal. For enumerations, this should be selected to match the underlying enumeration datatype.	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/InitialValue	Initial Value, for arrays this should be a comma separated list (e.g. you would enter: 10,20,30,40). Suffixes of “F”, “U”, etc should be on appropriate signals as required.	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Max	Maximum Value as indicated by m file defining signal.	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Min	Minimum Value as indicated by m file defining signal.	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadInMotCtrlRunnable	This flag indicates if a given signal is read in a runnable that runs at “MotorControl” or “MotorControlx2” rate	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadIn2msRunnable	This flag indicates if a given signal is read in a runnable that runs at 2ms (or slower) RTE task	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenInMotCtrlRunnable	This flag indicates if a given signal is written in a runnable that runs at “MotorControl” or “MotorControlx2” rate	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenIn2msRunnable	This flag indicates if a given signal is written in a runnable that runs at 2ms (or slower) RTE task	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Size	Size of signal. This needs to be 1 for standard signals and if greater than 1, the signal is considered to be an array	MotCtrlMgr
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Units	Units of signal as indicated by m file defining signal.	MotCtrlMgr

DaVinci Interrupt Configuration Changes

ISR Name	Interrupt Category (FE/EI)	Interrupt Channel Number	Priority Dependency	Notes
MotCtrlMgrIrq	EI	Needs to be gathered from program specific CM###_XXXXMcuCfg_Design component	Needs to be an appropriate priority for the high speed motor control interrupt	This ISR should be category 1 ISR and mapped to trusted application

Manual Configuration Changes

	Notes	SWC

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

This module defines all non-RTE motor control data structures

Required Global Data Outputs

This module defines all non-RTE motor control data structures

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger

Runnable	Scheduling Requirements	Trigger
MotCtrlMgrIrq	None	ISR – exact ISR source to be gathered from program specific CM###_XXXXMcuCfg_Design component
MotCtrlMgrPer1	MotCtrlMgrPer1 should execute near the start of the 2ms loop before any other functions that need data that is output by runnables running at the Motor Control rate. The DMA transfer that is populating MotCtrlMgr_TwoMilliSecFromMotCtrl_Rec shall run before MotCtrlMgrPer1 and ideally enough other functionality runs in-between these two events that the transfer can complete with minimal wait time in MotCtrlMgrPer1 (since this function is waiting for DMA transfer completion).	2ms RTE
MotCtrlMgrPer2	MotCtrlMgrPer2 should execute as the final function of the forward path to allow minimal lag on computation of new PWM commands in the Motor Control loop.	2ms RTE

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes
MotCtrl_START_SEC_CODE	Interrupt code	This code section also includes a static function scope variable, and therefore needs to open and close variable mapping statements and this should be mapped to the same application that the ISR is mapped to.
CDD_MotCtrlMgr_DmaWrite_START_SEC_VAR_INIT_128	Data that a DMA channel writes to during run-time	This gets mapped to a “.data_dma_128” section that will need to be explicitly added to the linker file. The intent of this section is to be placed in a RAM memory section that only the DMA has write access to (processor in user mode only has read access).

* Each …START_SEC… constant is terminated by a …STOP_SEC… constant as specified in the AUTOSAR Memory Mapping requirements.

Usage

Feature	RAM	ROM

NvM Blocks

None

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

<This section is for appendix>

2 - MotCtrlMgr Review

Overview

Summary Sheet
Synergy Project
Davinci Files
PolySpace
Integration Manual

Sheet 1: Summary Sheet

Rev 1.2

8-Jun-15

Peer Review Summary Sheet

Synergy Project Name:

kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. AR300A_MotCtrlMgr_Impl

Revision / Baseline:

kzshz2: Intended Use: Identify which Synergy revision of this component is being reviewed Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. AR300A_MotCtrlMgr_Impl_1.3.0

Change Owner:

kzshz2: Intended Use: Identify the developer who made the change(s) Rationale: A change request may have more than one resolver, this will help identify who made what change. Change owner identification may be required by indusrty standards. Lucas Wendling

Work CR ID:

EA4#6787

kzshz2: Intended Use: Intended to identify at a high level to the reviewers which areas of the component have been changed. Rationale: This will be good information to know when ensuring appropriate reviews have been completed. Modified File Types:

kzshz2: Intended Use: Identify who where the reviewers, what they reviewed, and if the reviewed changes have been approved to release the code for testing. Comments here should be at a highlevel, the specific comments should be present on the specific review form sheet. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. ADD DR Level Move reviewer and approval to individual checklist form Review Checklist Summary:

Reviewed:

MDD

Yes

Source Code

Yes

PolySpace

Yes

Integration Manual

Yes

Davinci Files

Comments:

No MDD updates required for this change. Source review was generated files and text templates.

Next rev of this component should bring in DataDictionary tool component as subproject if it has been created as standalone component.

General Guidelines:
- The reviews shall be performed over the portions of the component that were modified as a result of the Change Request.
- New components should include FDD Owner and Integrator as apart of the Group Review Board (Source Code, Integration Manual, and Davinci Files)
- Enter any rework required into the comment field and select No. When the rework is complete, review again using this same review sheet and select Yes. Add date and additional comment stating that the rework is completed.
- To review a component with multiple source code files use the "Add Source" button to create a Source code tab for each source file.
- .h file should be reviewed with the source file as part of the source file.

Sheet 2: Synergy Project

Peer Review Meeting Log (Component Synergy Project Review)

Quality Check Items:

Rationale is required for all answers of No

New baseline version name from Summary Sheet follows

Yes

Comments:

naming convention

Project contains necessary subprojects

Yes

Comments:

Project contains the correct version of subprojects

Yes

Comments:

Design subproject is correct version

Yes

Comments:

General Notes / Comments:

LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:

Change Owner:

Lucas Wendling

Review Date :

09/20/16

Lead Peer Reviewer:

Selva

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Jared J

Kathleen C

Sheet 3: Davinci Files

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Rationale is required for all answers of No

Only StdDef Port types are used

Comments:

Test component so no need of using

standardized interfaces

For components not using application data types, do all

Comments:

Test component so no need of using

port interface names end in PortIf and a sequence number

standardized interfaces

Non-program-specific components saved

Yes

Comments:

in Autosar 4.0.3 format

*Cfg.arxml.TT: Verfied Davinci Configurator imported the

Yes

Comments:

change correctly

*Cfg.h.TT: Verfied Davinci Configurator generates

Yes

Comments:

the configuration header(s) file correctly

kzshz2: Either a generic sandbox or a baselined integration project can be used to verify

All changed files have been compared against previous

Yes

Comments:

versions (If available)

kzshz2: Intended Use: Identify if previous version was compared and only the expected change(s) was present. This is for text files only, not binary or GUIs Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.

Automated validation check is performed

Yes

Comments:

Only for test developer project

Naming conventions followed. All names should

Comments:

Test component only, naming not

match DataDict.m

needed to follow conventions

Sender/Receiver port properties match DataDict.m

Yes

Comments:

Only for test developer project

file (use .m file helper tool)

Calibration port properties match DataDict.m

N/A

Comments:

file (use .m file helper tool)

Components using application data types:

Sender/Receiver port initialization values match

N/A

Comments:

DataDict.m file

Calibration port initialization values match

N/A

Comments:

DataDict.m file

Components not using application data types:

Sender/Receiver port initialization values match

Yes

Comments:

Only for test developer project

DataDict.m file and have been converted to counts

for fixed point types

Calibration port initialization values match

N/A

Comments:

DataDict.m file and have been converted to counts

for fixed point types

Mapping set and all unused items have been

Yes

Comments:

Only for test developer project

removed

All sender/receiver port read/writes using direct

Yes

Comments:

Only for test developer project

read/writes(List justification if not)

Runnable calling frequencies match FDD

Yes

Comments:

Only for test developer project

DataDict.m display variables: created as

N/A

Comments:

PerInstanceMemory. Matches the FDD

Component is correct component type

Yes

Comments:

Only for test developer project

General Notes / Comments:

Review .tt file generation and test developer/configurator project

Change Owner:

Lucas Wendling

Review Date :

09/20/16

Component Type :

CDD

Lead Peer Reviewer:

Selva

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Jared J

Kathleen C

Sheet 4: PolySpace

Rev 1.2

8-Jun-15

Peer Review Meeting Log (QAC/PolySpace Review)

Source File Name:

CDD_MotCtrlMgr.c (generated)

Source File Revision:

Source File Name:

CDD_MotCtrlMgr_Data.c (generated)

Source File Revision:

Source File Name:

CDD_MotCtrlMgr_Irq.c (generated)

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.01.00

Poly Space version:

Windows User: eg. 2013b 2013b

Polyspace sub project version:

Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 N/A

QAC version:

Windows User: eg 8.1.1-R 8.1.1-R

QAC sub project version:

Windows User: eg. TL_100A_1.1.0 TL100A_QACSuprt_1.2.0

Quality Check Items:

Rationale is required for all answers of No

Contract Folder's header files are appropriate and

kzshz2: Intended Use: Identify that the contract folder contains only the information required for this component. All other variables, constants, function prototypes, etc. should be removed. Rationale: This will help avoid unit testers having to considers object not used. It will also avoid having other files required for QAC.

Yes

Comments:

function prototypes match the latest component version

100% Compliance to the EA4 Static Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

Creager, Kathleen: use Browse Function Metrics, STCYC and STPTH

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

Samples of all generated source files were within scope of the analysis, this caused special versions of polyspace and qac projects (renamed from standard naming).

Change Owner:

Lucas Wendling

Review Date :

09/20/16

Lead Peer Reviewer:

Selva

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Jared J

Kathleen C

Sheet 5: Integration Manual

Rev 1.2

8-Jun-15

Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

kzshz2: Intended Use: Identify which file is being reviewed Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form. MotCtrlMgr Integration Manual.doc

Integration Manual Revision:

kzshz2: Intended Use: Identify which version of the integration manual has been reviewed. Rationale: Required for traceability between the MDD and review. Auditors will likely require this. 3

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

Yes

Comments:

General Notes / Comments:

Change Owner:

Lucas Wendling

Review Date :

09/21/16

Lead Peer Reviewer:

Selva

Approved by Reviewer(s):

Yes

Other Reviewer(s):

3 - MotCtrlMgr_MDD

Module Design Document

For

MotCtrlMgr

VERSION: 2

DATE: 10/28/15

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA

Location: The official version of this document is stored in the Nexteer Configuration Management System.

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial Version	Lucas Wendling	1	05/29/15
2	Updates for Signal Mapping	Lucas Wendling	2	10/28/15

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 MotCtrlMgr High-Level Description 6

4 Design details of software module 7

4.1 Graphical representation of MotCtrlMgr 7

4.2 Data Flow Diagram 7

4.2.1 Module level DFD 7

4.2.2 Sub-Module level DFD 7

4.3 COMPONENT FLOW DIAGRAM 7

5 Variable Data Dictionary 8

5.1 User defined typedef definition/declaration 8

5.2 Variable definition for enumerated types 8

6 Constant Data Dictionary 9

6.1 Program(fixed) Constants 9

6.1.1 Embedded Constants 9

6.1.1.1 Local 9

6.1.1.2 Global 9

6.1.2 Module specific Lookup Tables Constants 9

7 Software Module Implementation 10

7.1 Generated file description and logic 10

7.2 Initialization Functions 13

7.3 PERIODIC FUNCTIONS 13

7.3.1 Per1/Per2: 13

7.4 Non PERIODIC FUNCTIONS 13

7.5 Interrupt Functions 13

7.5.1 Isr: <ModuleName>_Isr<n)> 13

7.6 Serial Communication Functions 14

7.7 Local Function/Macro Definitions 14

7.8 GLObAL Function/Macro Definitions 14

7.9 TRANSIENT FUNCTIONS 14

8 Unit Test Considerations 15

9 Known Limitations With Design 16

10 Appendix 17

Abbrevations And Acronyms

Abbreviation	Description
DFD	Design functional diagram
MDD	Module design Document
	<ADD more to the table if applicable>

References

This section lists the title & version of all the documents that are referred for development of this document

Sr. No.	Title	Version
1	MDD Guidelines	Process 04.00.00
2	Software Naming Conventions	Process 04.00.00
3	Software Coding Standards	Process 04.00.00
4	AR300A_MotCtrlMgr_Design	See Synergy subproject version

MotCtrlMgr High-Level Description

None

Design details of software module

Graphical representation of MotCtrlMgr

None

Data Flow Diagram

None

Module level DFD

None

Sub-Module level DFD

None

COMPONENT FLOW DIAGRAM

None

Variable Data Dictionary

User defined typedef definition/declaration

<This section documents any user types uniquely used for the module.>

Typedef Name	Element Name	User Defined Type	Legal Range (min)	Legal Range (max)
MotCtrlToTwoMilliSecRec1	Elements are project specific and generated	struct
TwoMilliSecFromMotCtrlRec1	Elements are project specific and generated	struct
TwoMilliSecToMotCtrlRec1	Elements are project specific and generated	struct
MotCtrlFromTwoMilliSecRec1	Elements are project specific and generated	struct
MotCtrlIntRec1	Elements are project specific and generated	struct

Variable definition for enumerated types

Enum Name	Element Name	Value
Enumerations are project specific and generated

Constant Data Dictionary

Program(fixed) Constants

Embedded Constants

Local

Constant Name	Resolution	Units	Value
N/A

Global

Constant Name

N/A

Module specific Lookup Tables Constants

Constant Name	Resolution	Value	Software Segment
N/A

Software Module Implementation

Generated file description and logic

The following sections provide details on the logic used for generating the data and functions from the MotCtrlMgr configuration. The generator uses text templating to generate the appropriate file content based on the configuration details. The logic described in the following sections are implemented in the text template files provided in this component.

CDD_MotCtrlMgr_Irq.c

This file contains the definition of the interrupt service routine that Motor Control Manager defines. This interrupt service routine primarily contains a task list for executing runnables that are required to be scheduled at the motor control rate or motor control x2 rate. The following table lists the configuration parameters that are required in generation of this file:

Configuration Parameter	File Generation Usage Notes
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/Runnable	Used to determine the runnables needed to be called in the ISR task list
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/Runnable/RunnableRate	Used to determine if runnable needs to be called every ISR loop (MotorControl) or every other ISR loop (MotorControlx2)
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/IncludeHeaders	Used for include list required for this file for runnable prototype definitions
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/RunnableManagement/Runnable/SequenceOrder	Used to help define the relative calling sequence of the runnables in the ISR task list

CDD_MotCtrlMgr.c

This file contains the functions for the RTE interface. This file will receive appropriate signals from the RTE and provide appropriate signals to the RTE. Per1 provides updated signals to the RTE after the DMA transfer of the data successfully completed, and Per2 recieves signals from the RTE and then indicates to the DMA that the data is ready for transfer.

Configuration Parameter	File Generation Usage Notes
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal	Used for the name of the signals being read/written by the runnables being defined.
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenInMotCtrlRunnable	Used in conjuction with “/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadIn2msRunnable” to determine when a signal is needed to be managed by Per1
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadIn2msRunnable	Used in conjuction with “/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenInMotCtrlRunnable” to determine when a signal is needed to be managed by Per1
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenIn2msRunnable	Used in conjuction with “/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadInMotCtrlRunnable” to determine when a signal is needed to be managed by Per2
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadInMotCtrlRunnable	Used in conjuction with “/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenIn2msRunnable” to determine when a signal is needed to be managed by Per2
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Size	Used to determine if the signals being read/written by the runnables being defined are arrays (Impacts RTE API name).
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ImplementationDataType	Used to determine if the signals being read/written by the runnables being defined are boolean types (Impacts RTE API name).

CDD_MotCtrlMgr_Data.c

This file contains the definition of all of the structures containing the Motor Control ISR related signals. This includes providing initial values for all of the signals in the structure and padding the structure for proper structure size alignment restrictions.

Configuration Parameter	File Generation Usage Notes
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal	Used to determine signal names as part of the logic to determine if special grouping is needed for TSG3 signals
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenInMotCtrlRunnable	Used to determine which initial values are needed in which structure.
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadIn2msRunnable	Used to determine which initial values are needed in which structure.
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenIn2msRunnable	Used to determine which initial values are needed in which structure.
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadInMotCtrlRunnable	Used to determine which initial values are needed in which structure.
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Size	Used in the structure size calculation to determine how many pad bytes are needed for alignment at the end of the structure. Used also to add the appropriate braces for arrays on structure elements.
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ImplementationDataType	Used in the structure size calculation to determine how many pad bytes are needed for alignment at the end of the structure.
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/InitialValue	Used as the initializer value for a given signal in the structure
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/IncludeHeaders	Used for include list required for this file for definition of any intial values that may be required

CDD_MotCtrlMgr_Data.h

This file defines the structure definition of the Motor Control Data structures containing all Motor Control ISR related signals. It also defines any enumerations that need to be accessed by Non-RTE related code. Prototype statements for all Motor Control Data structures are included in this file as well as the macros defined for accessing individual signals of the Motor Control Data structures.

Configuration Parameter	File Generation Usage Notes
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum	Used to define enumeration accessed by Non-RTE related code. Used for enumeration name.
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum/EnumImplementationDataType	Used to define enumeration accessed by Non-RTE related code. Used for enumeration datatype.
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum/EnumElement	Used to define enumeration accessed by Non-RTE related code. Used for enumeration element name.
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/NonRteEnum/EnumElement/Value	Used to define enumeration accessed by Non-RTE related code. Used for enumeration element value.
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal	Used to determine signal names as part of the logic to determine if special grouping is needed for TSG3 signals. Also used as signal name for structure element definitions. Used to also determine name of signal access macros that are generated.
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenInMotCtrlRunnable	Used to determine the structure the signal should be added to.
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadIn2msRunnable	Used to determine the structure the signal should be added to
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenIn2msRunnable	Used to determine the structure the signal should be added to
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadInMotCtrlRunnable	Used to determine the structure the signal should be added to
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ImplementationDataType	Used to determine datatype of structure element. Also used as part of the structure size calculation to determine how many pad bytes are needed for alignment at the end of the structure.
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/EnumerationNameReference	Used to determine if a given signal is an enumeration and used to determine the corresponding enumeration name
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Size	Used in the structure size calculation to determine how many pad bytes are needed for alignment at the end of the structure. Used also to add the appropriate array size on signals that are arrays (having size > 1).
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/SignalMapping	Used for creation of motor control signal access macros for inputs that are named differently than outputs
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/SignalMapping/OutputSignalName	Output name for signal mapping (used to define an input signal macro definition)
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/SignalMapping/InputSignalName	Input name(s) for signal mapping (used to define the names of the signal macros)

AR300A_MotCtrlMgr_DataDict.m

This file is the generated data dictionary for MotCtrlMgr. This is intended to be used for documentation purposes as well as to aid in creating the AUTOSAR component description files.

Configuration Parameter	File Generation Usage Notes
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal	Used to determine signal name for I/O depending on signal useage.
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ImplementationDataType	Used to determine datatype of signal. Also used for stripping off c constant qualification (“U”, “L”, “F”) on standard datatypes that is assumed to be present in the initial value. Also used to convert boolean type initial values to “0/1” from “TRUE/FALSE”
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/EnumerationNameReference	Used to determine if a given signal is an enumeration and used to determine the corresponding enumeration name
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/InitialValue	Used for the initial value of a signal
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Size	Used to determine if the signal is an array and to set the format of the initial value appropriately
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/ReadIn2msRunnable	Used to determine if signal is an output from Per1 runnable
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/WrittenIn2msRunnable	Used to determine if signal is an input to Per2 runnable
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Max	Used for Maximum value property of signal
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Min	Used for Minimum value property of signal
/Nexteer/MotCtrlMgr/MotCtrlMgrConfigSet/SignalManagement/Signal/Units	Used for units property of signal

Initialization Functions

None

PERIODIC FUNCTIONS

Per1/Per2:

See section 7.1.2

Non PERIODIC FUNCTIONS

None

Interrupt Functions

Isr:

See section 7.1.1

Serial Communication Functions

None

Local Function/Macro Definitions

None

GLObAL Function/Macro Definitions

None

TRANSIENT FUNCTIONS

None

Unit Test Considerations

Known Limitations With Design

None

Appendix

4 - MotCtrlMgr DataDictionary Tool User Guide

Purpose

This document provides details on using the DataDictionary.exe tool for generating and testing the MotCtrlMgr component.

Overview

The MotCtrlMgr component is a project specific, highly configurable component. The majority of the configuration parameters of the component, however, can be derived from analysis of the collection of data dictionaries that exist within any given project. A tool was created (DataDictionary.exe) to create a file which contains the bulk of the MotCtrlMgr configuration which can subsequently be imported into the AUTOSAR Configuration Tools (Davinci Configurator). While this tool can primarily be used at a project configuration level, it also is used at a component level in the MotCtrlMgr component. The usage at a component level serves two primary purposes:

Generation of the majority of the MotCtrlMgr “test” configuration.

MotCtrlMgr component defines a “test” configuration. This test configuration is used for several purposes:

To exercise the .bswmd file containing the configuration parameters of MotCtrlMgr (for property correctness and Davinci Configuration compatibility)
To test for the proper/successful generation of the MotCtrlMgr component’s generated configuration files
To generate test files of all generated files of this component used to run static analysis checks on the generated file output, provide the possibility for unit testing of the generated files, and test compilation of the generated files.

Test of the DataDictionary.exe tool output.

Since the DataDictionary.exe tool is used at a project level with files that will change from project to project as needed, it is useful to have a fixed, known set of test files as inputs to the tool to test that the tool is providing the correct output with a known set of inputs. These input files can also be tailored to test different combinations of input scenarios to try to provide a robust set of test inputs to the tool.

Usage Steps for MotCtrlMgr Component Development

Unzip TestDataManagement.zip file into AR300A_MotCtrlMgr_Impl\tools\DataDictionary directory

This is needed since Telelogic synergy can’t currently recognize some of the folder names that are in this directory.

Update Data Dictionary input files in AR300A_MotCtrlMgr_Impl\tools\DataDictionary directory

This step is required if there are new or changed configurations that need to be tested. This step would be manually changing the .m files to add or change the configuration or this could also be done with the aid of matlab data dictionary tools.
Note: if new configurations include new/changed enumerations, these enumerations will need to be manually added into the “TestDataManagement” folder that was unzipped in step 1. And this update will need to be re-zipped for check-in to Synergy.
Note: if the new configurations include new signal mappings, the Mappings.xml file will need to be manually updated in the AR300A_MotCtrlMgr_Impl\tools\DataDictionary directory.

Rerun tool: AR300A_MotCtrlMgr_Impl\tools\DataDictionary\DataDictionary.exe to create new configuration file needed for the next step
1. Select “Cals” option from initial Data Dictionary tool options:

Select proper tools settings for generation of MotCtrlMgr configuration file. (note file paths may not be exactly the same as listed below):

Select “Generate” option in tool to create MotCtrlMgr.arxml configuration file.

Import MotCtrlMgr.arxml into MotCtrlMgr component Davinci Configurator project.

Notes: It is suggested to remove all configuration containers manually from the old configuration before importing the updated configuration. This allows easier import to ensure that older configuration is fully removed. Otherwise, much more care needs to be taken during the merge process to fully replace older configuration with newer configuration. Additionally, the configuration file does not contain runnable sequence number or header file include needs. These parameters will have to manually be filled out after the import process is complete (or the old configuration settings for these parameters can be kept).

Generate MotCtrlMgr component in Davinci Configurator.
Update Davinci Developer component for any updates needed from configuration changes.

The Davinci Developer component is manually maintained for MotCtrlMgr even though the source code for this component is generated. This component needs to be setup properly for any signals that flow between the MotCtrl Interrupt and RTE tasks. Any changes to Data Dictionary input files (new or changed signals) need to be updated in the Davinci Developer component. As a tip, the component needs to be properly configured to align with the content in AR300A_MotCtrlMgr_Impl\tools\contract\generate\CDD_MotCtrlMgr.c file.

Regenerate RTE contract headers for Davinci Developer component.

This step is done through the Davinci Configurator custom workflow steps that are configured in Davinci Configurator.