summaryrefslogtreecommitdiffstats
path: root/README.md
diff options
context:
space:
mode:
Diffstat (limited to 'README.md')
-rw-r--r--README.md138
1 files changed, 138 insertions, 0 deletions
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..3edb589
--- /dev/null
+++ b/README.md
@@ -0,0 +1,138 @@
+# IC service Cluster API
+
+## Overview
+
+This repository has 3 main elements:
+
+* Cluster API library code: ./src ./include
+* Test app for client: ./test/client_test
+
+## How to build
+
+```bash
+# ipc library is required by cluster_api, so please check ipc library and headers are installed in the system.
+$ ./buildtest.sh
+```
+
+## How to run
+
+* For client_test
+
+```bash
+$ ./buildtest.sh -d
+$ cd cmakeBuild/test/client_test
+$ ./client_test
+
+
+ CUnit - A Unit testing framework for C - Version 2.1-2
+ http://cunit.sourceforge.net/
+
+
+***************** CUNIT CONSOLE - MAIN MENU ******************************
+(R)un (S)elect (L)ist (A)ctivate (F)ailures (O)ptions (H)elp (Q)uit
+Enter command: ★(r)to run all test automatically ★(q)to terminate
+```
+
+# Source configuration
+
+- cluster_api/
+ - include/
+ - Set of external public headers
+ - src/
+ - cluster_api Library of implementation source
+ - test/
+ - client_test/
+ - Cluster API Test environment of implementation source
+
+# Build Configuration
+
+When ./buildtest.sh run, Build shows as follow:
+
+- cluster_api/
+ - cmakeBuild/
+ - src/
+ - The library of Cluster API as follows:
+ ```bash
+ libcluster_api.so -> libcluster_api.so.1
+ libcluster_api.so.1 -> libcluster_api.so.1.0.0
+ libcluster_api.so.1.0.0
+ ```
+ - test/
+ - client_test/
+ - Cluster API Test running files
+ ```bash
+ client_test
+ dummy_server
+ ```
+
+# Cluster API Implementation Content
+
+- API function which becomes I/F for application Implemented according to IC-Service_API_rev0.4.docx.
+- The main implementation of the process is to manage the data sent from the IC-Service server. When calling API from the application, extract only the relevant data from the managed data.
+- In addition to IC-Service_API_rev0.4.docx, the following two APIs have also been implemented:
+ - bool clusterInit(void)
+ - Initialization process for using the Cluster API.
+ - This API connects to the IC-Service server, assuming that the server has already started.
+ - Return true bool value if processing successfully.
+ - bool clusterTerm(void)
+ - Termination Cluster API Process.
+ - Used to disconnect from the IC-Service server.
+ - Return true bool value if processing successfully.
+- Applications that include cluster_api.h and link with libcluster_api.so can call every API.
+
+# client_test Test content
+
+Implement operation tests for every API of Cluster API. The configuration is as follows:
+
+- The test configures two executable files; client_test and dummy_server:
+ - client_test: Cluster API Test Body
+ - dummy_server: Mock IC-Service server used for Cluster API testing
+- When executing the test, only execute client_test.
+- dummy_server is automatically started within client_test.
+- The wait time for dummy_server to start and for dummy_server to send is 10 msec.
+ (Since it is asynchronous with another process, it does not work as intended without waiting all time)
+- client_test is an automated test program implemented using CUnit. All item tests and unit item tests are both possible according to CUnit specifications.
+- ※ The test may rarely fail due to the timing of inter-process communication.
+(Test all 156 items 20 times, return 1 item FAIL)
+
+Implementation of items test is as follows:
+
+1. InitAndTerm (5 Items)
+ - Verify that clusterInit() and clusterTerm() work as intended:
+ - Verify the operation when calling clusterInit(), and clusterTerm() sequentially、in the state of the IC-Service server exists (normal system).
+ - Verify that an error occurs due to an incorrect API call order:
+ - Call clusterInit() 2 times.
+ - Call clusterInit() then, call clusterTerm() 2 times.
+ - Without calling clusterInit(), call clusterTerm().
+ - Verify an error occurs when calling clusterInit()、in the state of the IC-Service server does not exist.
+2. Telltale (52 Items)
+ - Verify every API can obtain intended value as described in 3-4 Telltale of IC-Service_API_rev0.4.docx:
+ - Each API Implemented one pattern at a time.
+3. ShiftPosition (2 Items)
+ - Verify every API can obtain intended value as described in 3-5 ShiftPosition of IC-Service_API_rev0.4.docx:
+ - Each API Implemented one pattern at a time.
+4. Speed (2 Items)
+ - Verify every API can obtain intended value as described in 3-6 Speed of IC-Service_API_rev0.4.docx:
+ - Each API Implemented one pattern at a time.
+5. Tacho (1 Item)
+ - Verify every API can obtain intended value as described in 3-7 Tacho of IC-Service_API_rev0.4.docx:
+ - Each API Implemented one pattern at a time.
+6. TripComputer (20 Items)
+ - Verify every API can obtain intended value as described in 3-8 TripComputer of IC-Service_API_rev0.4.docx:
+ - Each API Implemented one pattern at a time.
+7. RegisterAndNotify (74 Items)
+ - Verify registerIcHmi() in 3-9 Register/Notify of IC-Service_API_rev0.4.docx works as intended:
+ - In the 1st argument arg_1, if IC_HMI_TT_ALL test assigned:
+ - Verify that the callback function is called whenever any of the 34 signals changed as described in 3-2-1 TellTale.
+ - Verify that the callback function is not called if none of the 34 signals have changed as described in 3-2-1 TellTale.
+ - Verify that the callback function is not called even if other signals than 34 signals have changed as described in 3-2-1 TellTale.
+ - In the 1st argument arg_1, If 0 assigned: Verify the callback function is not called even any of the 34 signals changed as described in 3-2-1 TellTale.
+ - In the 1st argument arg_1, if other flags than the following flags 3-2-1-1~3-2-1-34 are set: Verify the callback function is not called when any of the 34 signals changed as described in 3-2-1 TellTale.
+ - In the 2nd argument addr, if NULL assigned: Verify that an error occurs.
+ - In the 1st argument arg_1, if 3-2-1-1~3-2-1-34 are assigned set values. The following two procedures are implemented:
+ - Verify that the callback function is called only when the signal corresponding to the assigned flag is changed.
+ - Verify that the callback function is not called; even the other 33 signals changed.
+ - In the 1st argument arg_1, if one flag from 3-2-1-1~3-2-1-34 is assigned clear value. The following two procedures are implemented:
+ - Verify that the callback function is not called even if the signal corresponding to the cleared flag changed.
+ - Verify that there is no callback notification for an incorrectly cleared flag; even the other 33 signals changed.
+ (Callback notification for other signal changes occur)