Component Implementation

• 1: ES400A_TunSelnMngt_Integration_Manual
• 2: ES400A_TunSelnMngt_MDD
• 3: TunSelnMngt_PeerReview

1 - ES400A_TunSelnMngt_Integration_Manual

Integration Manual

For

ES400A TunSelnMngt

VERSION: 4.0

DATE: 29-Aug-2016

Prepared By:

Kevin Smith

Nexteer Automotive,

Saginaw, MI, USA

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

Revision History

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 NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

References

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

Dependencies

SWCs

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

None

Configuration REQUIREMeNTS

Build Time Config

Configuration Files to be provided by Integration Project

1. TunSelnMngt_Cfg_private.h – Genereated by Configurator

2. TunSelnMngt_Cfg_private.c – Genereated by Configurator

Da Vinci Parameter Configuration Changes

All the parameters are generated by the data dictionary tool based on the configuration for the project

DaVinci Interrupt Configuration Changes

Manual Configuration Changes

Exclusive Areas

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Required Global Data Outputs

Specific Include Path present

Yes. TunSelnMngt.h must also be included in Rte_UserTypes.h for non-RTE generated type definitions.

Runnable Scheduling

This section specifies the required runnable scheduling.

.

Memory Map REQUIREMENTS

Mapping

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

Usage

Table 1: ARM Cortex R4 Memory Usage

NvM Blocks

*See DataDict.m

Compiler Settings

Preprocessor MACRO

None

Optimization Settings

None

Appendix

Recommend GENy settings for CANembedded Projects

The following settings are recommend for online calibration support and DAQ access. This only applies to projects that XCP settings are generated by GENy.

2 - ES400A_TunSelnMngt_MDD

Module Design Document

For

TunSelnMngt

August 29, 2016

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Kevin Smith,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Table of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 TunSelnMngt & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of TunSelnMngt 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

4.2 Variable Data Dictionary 8

4.2.1 User Defined Typedef Definition/Declaration 8

4.2.1.1 Static Structures 8

4.2.1.2 Dynamic Structures and Enums 9

4.2.2 User Defined Enumerated Types 10

5 Software Component Implementation 11

5.1 Sub-Module Functions 11

5.1.1 Init: TunSelnMngtInit1 11

5.1.2 Per: TunSelnMngtPer1 13

5.2 Server Runnables 15

5.2.1 CopyCalPageReq 15

5.2.2 GetCalPageReq 16

5.2.3 GetSegInfoReq 17

5.2.4 OnlineTunRamAdrMpg 18

5.2.5 SetCalPageReq 19

5.3 Interrupt Functions 20

5.4 Module Internal (Local) Functions 20

5.4.1 SwtCalIdx 20

5.4.2 IdxChgMngt 21

5.4.3 MemCopy32Bit 23

5.4.4 MemCopy8Bit 24

5.4.5 SegModAdrInfo 25

5.4.6 SegModStdInfo 26

5.4.7 SegModAdrMpg 27

5.5 GLOBAL Function/Macro Definitions 28

6 Known Limitations with Design 29

7 UNIT TEST CONSIDERATION 30

Appendix A Abbreviations and Acronyms 31

Appendix B Glossary 32

Appendix C References 33

Introduction

Purpose

This MDD aids in documenting the implementation of ES400A Tuning Selection Management.

Scope

The following definitions are used throughout this document:

• Shall: indicates a mandatory requirement without exception in compliance.

• Should: indicates a mandatory requirement; exceptions allowed only with documented justification.

• May: indicates an optional action.

TunSelnMngt & High-Level Description

Tuning Selection Management (TunSelnMngt) provides the ability to change run-time calibrations during operation. The component also provides a RAM buffer for online calibration changes over XCP for tuning processes.

Design details of software module

Graphical representation of TunSelnMngt

Data Flow Diagram

None

Component level DFD

None

Function level DFD

None

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Values between the brackets [] are the ranges that the configurable constants could be defined as for a given integration. These values are generated by Configurator before the software build.

Variable Data Dictionary

The following type definitions are found in the private header of this component.

User Defined Typedef Definition/Declaration

Static Structures

The following table contains structures are static in their definition. However, internal elements may change based on the configuration of the project but the high level content is the same. These elements are described at the bottom of the table.

Rte_ParameterRefTabType is a structure of void pointers that point to the various calibration component structures. This type is generated by the RTE based on the configuration of the integration.

Dynamic Structures and Enums

The following table contains structures are dynamic in their definition. The contents contained will vary from project to project. The intent of this table is to document their purpose.

User Defined Enumerated Types

Software Component Implementation

Sub-Module Functions

Init: Init1

Design Rationale

The initialization function creates two copies of the RTE generated flash table in to RAM. A CRC is performed on each of the copies to ensure that they match. The function also adjusts the tables to load the appropriate initialization and run-time calibrations indexes that are required by the application.

Processing

Module Outputs

None

Per: Per1

Design Rationale

Processing

Module Outputs

None

Server Runnables

CopyCalPageReq

Design Rationale

This function is called by the XCP master and queues the copy of the calibrations contained in the selected group, or segment, into the RAM buffer. The actual copy is performed by TunSelnMngt’s main periodic function, but this runnable logs the current state of TunSelnMngt and marks the copy in progress.

(Processing of function)………

Module Outputs

None

GetCalPageReq

Design Rationale

This function is called by the XCP master and returns the page with the request XCP and ECU access for a given segment.

(Processing of function)………

Module Outputs

None

GetSegInfoReq

Design Rationale

This function is called by the XCP master and returns the requested information for the provided segment.

(Processing of function)………

Module Outputs

None

OnlineTunRamAdrMpg

Design Rationale

This function is called by the XCP master. During tuning, tools such as eTool and CANape will read calibration values from their flash addresses because that is how the A2L file is defined. However, when the calibrations are access from RAM, the user does not always know the exact address the calibration is located. This function calculates the RAM address for a given calibration to the XCP function for reading and writing.

(Processing of function)………

Module Outputs

None

SetCalPageReq

Design Rationale

This function is called by the XCP master. This function will set the status of the calibration page for a given segment.

(Processing of function)………

Module Outputs

None

Interrupt Functions

None

Module Internal (Local) Functions

SwtCalIdx

Design Rationale

This function manages the RAM buffer access and switches the calibration index between the two copies in RAM.

Processing

IdxChgMngt

Design Rationale

Processing

MemCopy32Bit

Design Rationale

The 32-bit mem copy function is used to move calibration pointers from flash to RAM. The void pointers are internally assigned to a uint32 pointer before the processing loop begins.

Processing

MemCopy8Bit

Design Rationale

The 8-bit mem copy function is used to move calibration segments into the RAM space. Since the length of the segments is not guaranteed to be a 32-bit even address, 8-bit was selected to ensure that only the bytes required to be moved are performed. The void pointers are internally assigned to a uint8 pointer before the processing loop begins.

Processing

SegModAdrInfo

Design Rationale

Processing

SegModStdInfo

Design Rationale

Processing

SegModAdrMpg

Design Rationale

Processing

TunSelnMngt_ChkXcpWrAcs

Design Rationale

This function is generated based on the configured access regions in Configurator. Below is just a high level overview of the function. The conditions in the if statements are logically OR’d together to form the tests.

Processing

GLOBAL Function/Macro Definitions

None

Known Limitations with Design

1. None

UNIT TEST CONSIDERATION

None

Abbreviations and Acronyms

Glossary

Note: Terms and definitions from the source “Nexteer Automotive” take precedence over all other definitions of the same term. Terms and definitions from the source “Nexteer Automotive” are formulated from multiple sources, including the following:

• ISO 9000

• ISO/IEC 12207

• ISO/IEC 15504

• Automotive SPICE® Process Reference Model (PRM)

• Automotive SPICE® Process Assessment Model (PAM)

• ISO/IEC 15288

• ISO 26262

• IEEE Standards

• SWEBOK

• PMBOK

• Existing Nexteer Automotive documentation

References

3 - TunSelnMngt_PeerReview

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. ES400A_TunSelnMngt_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. 1.2.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. Kevin Smith

Work CR ID:

EA4#7238

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:

Yes

MDD

Yes

Source Code

Yes

PolySpace

Yes

Integration Manual

Yes

Davinci Files

Comments:

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.