1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97
| Requirement
1 Introduction
1.1 Purpose
The purpose of this document is to specify all requirements for a SW development project. The requirement specification contains all requirements needed to carry out the SW development and to fulfil system requirements in the SYRS. The SYRS is partitioned into subsystem requirements and the SW specific requirements are broken down into SW requirements that will define and control the SW development project.
1.2 Background
The scope of the project is to develop a PRND shifter with a single hall sensor per position, thus removing the traditional sensor redundancy.
A special care should be made on SW test to simulate a failed sensor (OFF/ON) and make sure the shifter broadcast the right position.
1.3 Requisite Documents
Complete list of documents referenced in this SWRS.
Document Description
SYRS Sytem Requirement Specification
SWDP SW Development Plan
SWDPROC SW Development Process description
2 Terminology
2.1 Definitions
Definition Description
Safety plan The safety plan for a project includes the planning of the activities and procedures for achieving functional safety
Safety concept Safety requirements and their allocation to elements to achieve the safety goals
Work product Anything produced in the project (documents, source code files, executable files...)
2.2 Abbreviations
Abbreviation Description
ASIL Automotive Safety Integrity Level
EOL End Of Line (production)
FSR Functional Safety Requirement
HMI Human Machine Interface
HW Hardware
SW Software
3 Requirements Identification
State how requirements are identified and tagged, including the format for requirement tags. State if a requirements management tool is used and what impact it has on the requirement specifications format.
Tag example: [SW x:y] where x = group # and y = identifier #
Functional safety requirements shall be clearly identified.
Tag example: [SW FSR x:y]
These examples can be used if no other format is specified.
4 Requirements Traceability
Provide an overview of the requirements using the requirement tags and how they are mapped to system requirements. Provide a table to map the requirements using the following as an example:
System requirement SW requirement Description
[SY x1:y1] [SW x1:y1] Shifter must broadcast its position all the time
[SW x1:y2] Shifter must broadcast SH_FAIL_OFF message with the current position when a sensor fail off
SW x1:y3] Shifter must broadcast SH_FAIL_ON message with the current position when a sensor fail on
[SY x2:y1] [SW x2:y1] Shifter must broadcast its position between 6V and 16V
[SW x2:y2] Shifter must recover from a CAN BUS OFF
[SY x3y1] [SW x3:y1] MISRA-C compliance
5 System Overview
Provide an overview of the system, of the SW system in its system and HW environment. Describe briefly function blocks and interfaces, preferably using figures and block diagrams.
TCM: Transmission control, receive position via CAN from shifter and change gear
Shifter: Sends lever position to TCM via CAN messages
6 Requirements
6.1 Normal state
ID: SW x1:y1
Shifter must broadcast its position all the time. Test should be done from R to D as fast as we can to verity that the shifter detects all position
6.2 Error states
ID: SW x1:y2
Shifter must broadcast SH_FAIL_OFF message with the current position when a sensor fail off.
ID: SW x1:y3
Shifter must broadcast SH_FAIL_ON message with the current position when a sensor fail on
6.3 Power Requirements
ID: SW x2:y1
Shifter must broadcast its position between 6V and 16V
6.4 CAN Interface
ID: SW x2:y2
Shifter must recover from a CAN BUS OFF
6.5 Coding Standards
ID: SW x3:y1
Code must be MISRA-C 2004 compliant |
Partager