Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/Expand PutFile #70

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,139 @@
## Functional requirements

1.
In case

Mobile application sends a PutFile "Single Frame" with a known counted checksum to the SDL

SDL must
- receive PutFile "Single Frame"
- verify the counted checksum from the app (by comparing actual and received checksum)
- respond the app with result code "SUCCESS"

2.
In case

Mobile application sends a PutFile "Single Frame" with a known wrong counted checksum to the SDL

SDL must
- receive PutFile "Single Frame"
- verify the counted checksum from the app
- respond with result code "CORRUPTED_DATA"

3.
In case

Mobile application sends a PutFile "Multiple Frame" with a known counted checksum to the SDL.

SDL must
- receive PutFile "Multiple Frame"
- verify the counted checksum from the app
- respond with result code "SUCCESS"

4.
In case

Mobile application sends a PutFile "Multiple Frame" with a incorrect counted checksum to the SDL

SDL must
- receive PutFile "Multiple Frame"
- verify the counted checksum from the app
- respond with result code "CORRUPTED_DATA"

5.
In case

Mobile application sends a PutFile without parameter `crc` to the SDL

SDL must
- receive PutFile without parameter `crc`
- upload data
- respond with resultCode: "SUCCESS"

6.
In case

Mobile application sends file via PutFile chunks
and SDL process some part of chunks with success result code
and one chunk came with wrong crc value and SDL responds with result code "CORRUPTED_DATA" to mobile app

SDL must
- response "CORRUPTED_DATA"
- process all other chunks with resultCode "INVALID_DATA"

7.
In case

Mobile application sends a PutFile "Single Frame" with a negative (not valid) checksum to the SDL

SDL must
- SDL receive putfile "Single Frame" and counted checksum
- respond with result code "INVALID_DATA"

8.
In case

Mobile application sends a PutFile "Multiple Frame" with a negative (not valid) checksum to the SDL

SDL must
- SDL receive putfile "Multiple Frame" and counted checksum
- respond with result code "INVALID_DATA"

9.
In case

Mobile application sends a putfile "Single Frame" with a more than maxvalue (not valid) checksum to the SDL

SDL must
- receive putfile "Single Frame" and counted checksum
- respond with result code "INVALID_DATA"

10.
In case

Mobile application sends a putfile "Multiple Frame" with a more than maxvalue (not valid) checksum to the SDL

SDL must
- receive putfile "Multiple Frame" and counted checksum
- respond with result code "INVALID_DATA"


11.
In case

Mobile application sends a PutFile with correct checksum
and some bytes of the data were corrupted

SDL must
- receive PutFile
- verify counted checksum
- respond with result code "CORRUPTED_DATA"

## Non-functional requirements
Addition to MOBILE API:
```
<enum name="Result" internal_scope="base">
<element name="CORRUPTED_DATA">
<description>The data sent failed to pass CRC check in receiver end</description>
</element>
</enum>


<function name="putFile" functionID="putFileID" messagetype="request">
[...]
<param name="crc" type="Integer" minvalue="0" maxvalue="4294967295" mandatory="false">
<description> Additional CRC32 checksum to protect data integrity up to 512 Mbits . </description>
</param>
[...]
</function>


<function name="putFile" functionID="putFileID" messagetype="response">
[...]
<param name="resultCode" type="Result" platform="documentation">
<description>See Result</description>
<element name=" CORRUPTED_DATA "/>
</param>
[...]
</function>
```
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
## Use Case 1: Processing putFile request with CRC32 checksum

_Pre-conditions:_
a. SDL and HMI are started
b. Mobile application is successfully registered and running on SDL

_Steps:_

1. Mobile application sends a request to uploade a file as chunks to SDL
2. The request has known correct counted checksum

_Expected:_

3. SDL verifies the counted checksum from the mobile application - valid
4. SDL responds with successful result code to mobile application

**Exception 1:**

2.1.1 The request has known wrong counted checksum
2.1.2 SDL responds with result code "CORRUPTED_DATA" to mobile application

**Exception 2:**
2.2.1 The request has negative (not valid) checksum
2.2.2 SDL responds with result code "INVALID_DATA" to mobile application

**Exception 3:**
2.3.1 The request has `value` more than `maxvalue`
2.3.2 SDL responds with result code "INVALID_DATA" to mobile application

**Exception 4:**
2.4.1 The request has no counted checksum
2.4.2 SDL uploads data and responds with successful result code to mobile application

**Alternative flow 1**
2.a.1 SDL processes some parts of chunks successfully and one chunk comes with wrong checksum value
2.a.2 SDL responds with result code "CORRUPTED_DATA" to mobile application
2.a.3 SDL responds with result code "INVALID_DATA" if mobile application sends further chanks

**Alternative flow 2**
2.b.1 The request has correct checksum and some bytes of the data were corrupted
2.b.2 SDL responds with result code "CORRUPTED_DATA" to mobile application