rename temp to en/Intel-CCAI-Development-Manual/assets
|
@ -12,7 +12,7 @@ dateCreated: 2022-03-11T03:18:01.489Z
|
|||
|
||||
CCAI provides many FCGI APIs. They are named `fcgi_xxxx`. Each fcgi API is a fcgi server, running in the background. Client APPs communicate with the fcgi server by using http post protocol.
|
||||
|
||||
![image7.png](/temp/image7.png)
|
||||
![image7.png](./assets/image7.png)
|
||||
|
||||
These fcgi APIs will do AI for different cases, such as classification, face detection, OCR, TTS, or ASR. Please refer to the following API list to understand the specific API.
|
||||
|
||||
|
@ -20,7 +20,7 @@ Some fcgi APIs have two working modes. One mode is doing inference locally in th
|
|||
|
||||
The following picture shows two working modes.
|
||||
|
||||
![image5.png](/temp/image5.png)
|
||||
![image5.png](./assets/image5.png)
|
||||
|
||||
Some FCGI APIs are implemented by two languages, C++ and python. So some APIs have two types of API: python API and C++ API. Both python API and C++ API provide the same functionality and parameters. The only difference is they have different http addresses. So clients' apps can get the same inference result from either FCGI C++ API or python API by using different addresses.
|
||||
|
||||
|
@ -984,7 +984,7 @@ This service is used to monitor the CCAI container.
|
|||
|
||||
CCAI framework not only provides FGCI APIs, but also provides many gRPC APIs. Client APPs can do inference by calling gRPC APIs.
|
||||
|
||||
![image14.png](/temp/image14.png)
|
||||
![image14.png](./assets/image14.png)
|
||||
|
||||
The following are detailed gRPC APIs.
|
||||
|
||||
|
@ -1158,7 +1158,7 @@ Runtime APIs are *“simple” *APIs. *“simple”* means the number of APIs is
|
|||
|
||||
The runtime service library APIs are implemented by two kinds of languages, C++ and python. So it provides two types of APIs. One type is C++ APIs, it can be called by C++ programs directly. Another is python APIs, it is prepared for python programs.
|
||||
|
||||
![image13.png](/temp/image13.png)
|
||||
![image13.png](./assets/image13.png)
|
||||
|
||||
**Notice:**
|
||||
|
||||
|
|
|
@ -15,7 +15,7 @@ dateCreated: 2022-03-11T03:18:05.283Z
|
|||
|
||||
The picture below is showing the basic working model of CCAI as a whole services provider to provide high level APIs to external users of the services container. Basically, there are 2 methods to use those services which are provided in REST/gRPC APIs form. One is calling those APIs directly, the other one is calling simulation lib APIs (we will talk simulation lib later).
|
||||
|
||||
![image2.png](/temp/image2.png)
|
||||
![image2.png](./assets/image2.png)
|
||||
|
||||
# CCAI (1.1 release) stack architecture
|
||||
|
||||
|
@ -24,4 +24,4 @@ The picture below is showing the basic working model of CCAI as a whole services
|
|||
|
||||
The architecture picture below is showing those modules and stacks in a high level picture, it shows CCAI’s components and their dependencies. It is up to date for CCAI 1.1 release.
|
||||
|
||||
![image1.png](/temp/image1.png)
|
||||
![image1.png](./assets/image1.png)
|
|
@ -10,7 +10,7 @@ dateCreated: 2022-03-11T03:18:07.757Z
|
|||
|
||||
# CCAI service work mode
|
||||
|
||||
![image4.png](/temp/image4.png)
|
||||
![image4.png](./assets/image4.png)
|
||||
|
||||
AI services for CCAI include two parts, one is client-side, the other is server-side. Customer applications are running on client-side. The CCAI services are running on server-side. Client-side sends http post requests or gRPC requests to server-side, and server-side replies responses to client-side. So developing AI services means development of server-side programs.
|
||||
|
||||
|
@ -140,7 +140,7 @@ Now you can verify your services by your test application from the host.
|
|||
|
||||
- Create a directory */opt/intel/service_runtime/service/your-service/* and put your binary file in this directory. Create a directory */opt/intel/service_runtime/service/lighttpd/conf-enabled/* and put your configuration file to this directory. The directory hierarchy example:
|
||||
|
||||
![image9.png](/temp/image9.png)
|
||||
![image9.png](./assets/image9.png)
|
||||
|
||||
- Give permission for the user www-data to access your files, example:
|
||||
|
||||
|
|
|
@ -198,11 +198,11 @@ If you want change the default configuration, you can execute ‘make menuconfig
|
|||
```bash
|
||||
$>make menuconfig
|
||||
```
|
||||
![image18.png](/temp/image18.png)
|
||||
![image18.png](./assets/image18.png)
|
||||
|
||||
You can type ‘Space/Enter’ to expand a branch, or ‘enable/disable’ an option.
|
||||
|
||||
![image19.png](/temp/image19.png)
|
||||
![image19.png](./assets/image19.png)
|
||||
|
||||
```bash
|
||||
$> make base_image
|
||||
|
@ -309,7 +309,7 @@ $ ./release_build.sh image
|
|||
|
||||
You will get 3 Docker images as shown below:
|
||||
|
||||
![image20.png](/temp/image20.png)
|
||||
![image20.png](./assets/image20.png)
|
||||
|
||||
b) The image service_runtime needs to be installed to OS on the target device, and the image service_runtime_openvino and the image service_runtime_base need to be saved for future incremental OTA image creation.
|
||||
|
||||
|
@ -336,7 +336,7 @@ If there is no the image service_runtime_openvino found, you may need to pull it
|
|||
$ docker pull REGISTRY_SERVER/service_runtime_openvino:ubuntu_20.04
|
||||
$ docker tag REGISTRY_SERVER/service_runtime_openvino:ubuntu_20.04 service_runtime_openvino:ubuntu_20.04
|
||||
```
|
||||
![image21.png](/temp/image21.png)
|
||||
![image21.png](./assets/image21.png)
|
||||
|
||||
b) Build the image service_runtime following those instructions in CCAI build document
|
||||
|
||||
|
@ -346,7 +346,7 @@ $ ./release_build.sh image
|
|||
|
||||
You will get the Docker image service_runtime which should be installed to the OS of the target device.
|
||||
|
||||
![image22.png](/temp/image22.png)
|
||||
![image22.png](./assets/image22.png)
|
||||
|
||||
Example 3, There is a new CCAI release, where both the layer service_runtime_openvino and the layer service_runtime are changed.
|
||||
|
||||
|
@ -363,7 +363,7 @@ $ docker pull REGISTRY_SERVER/service_runtime_base:ubuntu_20.04
|
|||
$ docker tag REGISTRY_SERVER/service_runtime_base:ubuntu_20.04 service_runtime_base:ubuntu_20.04
|
||||
```
|
||||
|
||||
![image24.png](/temp/image23.png)
|
||||
![image24.png](./assets/image23.png)
|
||||
|
||||
b) Build both the image service_runtime_openvino and the image service_runtime respectively.
|
||||
|
||||
|
@ -371,7 +371,7 @@ b) Build both the image service_runtime_openvino and the image service_runtime r
|
|||
$ ./release_build.sh openvino_image
|
||||
$ ./release_build.sh image
|
||||
```
|
||||
![image24.png](/temp/image24.png)
|
||||
![image24.png](./assets/image24.png)
|
||||
|
||||
c) The newly generated image service_runtime needs to be installed to the OS of the target device, and the newly generated image service_runtime_openvino needs to be updated to your registry server.
|
||||
|
||||
|
|
|
@ -10,7 +10,7 @@ dateCreated: 2022-03-11T03:18:15.834Z
|
|||
|
||||
As mentioned above in chapter 6, CCAI services work mode are:
|
||||
|
||||
![image7.png](/temp/image4.png)
|
||||
![image7.png](./assets/image4.png)
|
||||
|
||||
AI services for CCAI include two parts, one is client-side, the other is server-side. Customer applications are so called client-side. The CCAI services are server-side. Client-side sends http post requests or gRPC requests to server-side, and server-side replies responses to client-side.
|
||||
|
||||
|
|
|
@ -21,4 +21,4 @@ In brief, one AI services API framework with the same development mode like deve
|
|||
* **Intel** - platform differentiating capability developed by Intel
|
||||
{.grid-list}
|
||||
|
||||
![image8.png](/temp/image8.png)
|
||||
![image8.png](./assets/image8.png)
|
||||
|
|
Before Width: | Height: | Size: 104 KiB After Width: | Height: | Size: 104 KiB |
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 42 KiB |
Before Width: | Height: | Size: 7.5 KiB After Width: | Height: | Size: 7.5 KiB |
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 25 KiB |
Before Width: | Height: | Size: 8.3 KiB After Width: | Height: | Size: 8.3 KiB |
Before Width: | Height: | Size: 7.0 KiB After Width: | Height: | Size: 7.0 KiB |
Before Width: | Height: | Size: 36 KiB After Width: | Height: | Size: 36 KiB |
Before Width: | Height: | Size: 26 KiB After Width: | Height: | Size: 26 KiB |
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 42 KiB |
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 71 KiB After Width: | Height: | Size: 71 KiB |
Before Width: | Height: | Size: 34 KiB After Width: | Height: | Size: 34 KiB |
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 32 KiB After Width: | Height: | Size: 32 KiB |
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 40 KiB |
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 42 KiB |
Before Width: | Height: | Size: 7.5 KiB After Width: | Height: | Size: 7.5 KiB |
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 21 KiB |
Before Width: | Height: | Size: 34 KiB After Width: | Height: | Size: 34 KiB |
Before Width: | Height: | Size: 6.1 KiB After Width: | Height: | Size: 6.1 KiB |
Before Width: | Height: | Size: 62 KiB After Width: | Height: | Size: 62 KiB |
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
BIN
temp/image8.png
Before Width: | Height: | Size: 62 KiB |