Version: 1 Date June 3, 2015
Download 328.3 Kb.
|
- Navigate this page:
- 1.4.1SOTA Core Server [SRV]
- 1.4.3External Resolver [EXT-RESOLV]
- 1.4.4EXTERNAL RESOLVER API [EXT-RESOLV-*-API]
- Server deployment environment
- Client deployment environment
- Deliverables 1.5Device-side deliverables
- 1.6Server-side deliverables
- 1.7Format of deliverables
- Licenses / Intellectual Property
- Software / Deliverable Management
- Appendix A – Requirement Specification
1.3SOTA Protocol and RVIThe Device and Core Server will both use RVI (http://github.com/PDXostc/rvi_core) to manage data links and basic protocols. Higher level flows (see use cases layout in the SOTA Client / Device chapter) are managed by the SOTA Client and Core Server. The lower level protocol, including authentication, authorization, and service invocation, will be implemented using JSON over either HTTP or direct over TCP/IP. RVI will also be used to transmit and receive wakeup SMS messages used to trigger a Device connection to the SOTA Server. JSON is chosen as a core format to simplify implementation and avoid the overhead and complexity of, for example, OMA-DM FUMA. The plugin structure of RVI makes it relatively easy to expand the protocol suite with additional data links and protocols to support various industry standards OEM-specific proprietary systems. All interaction between the SOTA Client and the Device-side RVI will be done through JSON-PRC, as will all interaction between the SOTA Core Server and the Server-side RVI. The RVI protocol will handle the following features, which are outside the scope of the Statement of Work: 3G/LTE Connection setup Once instructed by the SOTA Client to setup a mobile data connection to the SOTA Server, RVI will handle all modem interfacing, including PPP link setup, AT command set integration (3GPP TS 27.007), IP address assignment, and other low-level processes. Server and Device SMS management The Server-side RVI will provide integration to at least well-known SMS service provider using SOAP, JSON, SMPP 3.4, or similar protocols. It is up to the vendor to setup accounts and access to the SMS service provider for testing and demonstration. The Device-side RVI will also provide mobile terminal integration necessary to receive SMS through the 3GPP TS 27.005 standard. A wakeup SMS will be delivered as a JSON-RPC command to the SOTA Client. Authentication and Authorization Server-to-Device and Device-to-Server authentication and authorization is carried out by RVI using certificates signed through root certificates stored locally on both sides. If a service, such as download start or software update notification is delivered by Device RVI to the SOTA Client or Server, the command can be considered authenticated and authorized. Discovery The SOTA Server will be notified by the server RVI when a Device becomes available for communication. A similar notification will be delivered when the Device is disconnected, either by choice or network error. The SOTA Client will be notified by the Device RVI when a server becomes available, or unavailable, for communication. Store and Forward If a command, such as finalize download cannot immediately be delivered, RVI will store it for a given time period while waiting for the receiver to become available. The time period can span from a few seconds to several weeks or even months. Device side WiFi connectivity RVI will handle automatic WiFi access point authentication and connection through ConnMan or similar system. 1.4SOTA ServerThe SOTA Server is responsible for managing, selecting, queueing, transmitting and verifying software updates to be installed on Devices. Figure 3 below shows the Server structure  Figure 3. Server components. Green boxes are covered by the Statement of Work.
1.4.1SOTA Core Server [SRV]The SRV component is responsible for all business logic. The features of the SRV component are as follow: Vehicle management [SRV-VIN] A minimalistic vehicle management system storing VIN and package installed on it. Software package management [SRV-PACKAGE] The software package management handles the binary image of packages that are to be transferred to the fleet. Package queueing [SRV-PACKAGE-QUEUE] The queueing mechanism is used to line up packages for distribution and installation on vehicles. The queue manager invokes the External Resolver to translate the package to be installed into a set of VINs. Once a set of VIN has been identified as targets for a package, the currently installed set of software on each VIN is analysed to determine which prerequisite packages need to be bundled with the original package to satisfy all dependencies. The completed VIN-specific bundle is then queued for transmission to the vehicle. Traffic shaping / Campaign management [SRV-TRAFFIC-SHAPING] The traffic shaping manager allows packages to be transmitted to their target VINs within the constraints of data plans and their cyclic (monthly) data pools, thus avoiding over data charges. Package transmission and reporting [SRV-PACKAGE-TRANSMIT] A queued package will trigger a wakeup / shoulder tap SMS to the targeted VIN, which will then call back in with a mobile data connection to download the package. See “SOTA Protocol” chapter for protocol specifics. 1.4.2SOTA API [API]The SOTA API exports the Core Server functionality to external systems through a Web API. The API can either be used by the Web Server or by existing logistic / provisioning system with a deep knowledge of the managed fleet. The following interfaces are exposed by the API. Vehicle management [API-VIN] Covers the interface to add, delete and search VINs. Components can be added to existing VINs. Software packages can be added (as pre-installed packages) to VINs. Finally, the VIN API support retrieval of software installation reports for the managed VINs. Component management [API-COMP] The component API enables external systems to add components and search for vehicles that components are installed on. Package management [API-PACKAGE] Allows an external system to upload software packages and store it in the database. The package API can also be used to search for packages. Queue management [API-QUEUE] Allows external systems to request that a software package is to be installed on all VINs that pass a provided filter. The queue API also allows for the cancellation of pending package installs, installation report retrievals, and search functionality for pending updates. Traffic shaping [API-SHAPING] The traffic shaping API supports commands to add and manage data plans and their individual billing cycles and data pools. The API is also used to add consumed data to the currently active billing cycle and to report billing cycle usage. 1.4.3External Resolver [EXT-RESOLV]The external resolver is used to translate a package ID that is to be installed into a set of VIN numbers that should receive the package. When the SOTA system receives a command to install a package, the SOTA Core Server will query the External Resolver providing the package ID as an argument. The VINs returned by the Resolver will have the package queued for installation. The Resolver will also handle package dependencies, maintaining a list of which packages are currently installed on which VIN and which packages need to be bundled with an update in order for the install to succeed. The reference implementation of the resolver uses a Boolean algebra filter operating on the VIN, installed components, and installed software on a vehicle to determine if it is eligible to install the package. The features of the resolver are as follows: Vehicle management [EXT-RESOLV-VIN, EXT-RESOLV-COMP] A minimalistic vehicle management system storing VIN numbers with zero or more components on it. Each component (IVI, TCU, etc) has a part number, a description, and a list of VINs it is installed on. Software package management [EXT-RESOLV-PACKAGE] The software package management keeps track of which packages are installed on which vehicles, enabling the resolver to run filters that match against currently installed software to determine which VINs to push a package to. Software package dependencies [EXT-RESOLV-DEPS] The software package dependencies keeps track of which dependent-upon packages are needed by a specific package in order for its install to succeed. When a package is to be transmitted to a VIN for installation, the Resolver compares the list of currently installed packages on the VIN against the list of dependent-upon packages. If any dependent-upon packages are missing on the VIN, the SOTA Core Server will be notified about them when the package is resolved for the given VIN. Filter management [EXT-RESOLV-FILTER] Boolean expressions are used to determine which VINs a package should be installed on. Expressions, used as filters, can require that a specific component must be installed on a VIN in order for it to pass the filter, that the VIN matches a specific pattern, or that another software package is installed on the VIN, etc. Component manager [EXT-RESOLV-COMP] Components can be added to the system, with a part number and description and then marked as installed on one or more VINs, allowing the filter mechanism to specify that components must be installed on a VIN in order for them to have a package installed. 1.4.4EXTERNAL RESOLVER API [EXT-RESOLV-*-API]The External Resolver API the component functionality to other systems through a Web API. The API can either be used by the Web Server or by existing logistic / provisioning system with a deep knowledge of the managed fleet. The following interfaces are exposed by the API. Vehicle management [EXT-RESOLV-VIN-API] Covers the interface to add, delete and search VINs. Components can be added to existing VINs. Software packages can be added (as pre-installed packages) to VINs. Finally, the VIN API support retrieval of software installation reports for the managed VINs. Component management [EXT-RESOLV-COMP-API] The component API enables external systems to add components and search for vehicles that components are installed on. Package management [EXT-RESOLV-PACKAGE-API] Allows an external system to upload software packages and create a package around it together with the dependencies needed for the package to operate in a VIN. The package API can also be used to search for vehicles. Filter management [EXT-RESOLV-FILTER-API] The filter API allows external systems to create, label, and validate Boolean expressions used to filter out VINs targeted by a specific package. 1.4.5Web Server [WEB]The Web server is used to expose the SOTA API as a web application that can be used by an administrator or agent to manage the system. The Web Server converts each SOTA API section into a user interface that translates into one or more API calls to carry out the actual work. The web server will forward select user interface actions such as VIN and package provisioning both to the SOTA API and the equivalent External Resolver API. Resolver-specific user interface actions, such as component provisioning, are forwarded only to the Resolver. 1.4.6FiltersA filter, as mentioned above, is used to identify a subset of all managed VINs that should receive a specific software package. Multiple number of filters can be setup and, when a software package is queued for transmission, one or more of the filters are selected for that specific transmission. Each VIN, together with its installed software packages, components and other factors are then matched against the filters. If the VIN passes all selected filters, the package will be transmitted to that VIN. Filters are designed as Boolean expressions where the operands are things such as the VIN matching a given pattern, a component being installed on the VIN, or a specific package already being available on the targeted VIN, etc. A typical filter scenario is that an update to the nav system should only be distributed to VINs that have the nav system component installed. Another example is that a 3D surround sound system bug fix should only be distributed to a specific VIN series that has the premium sound component installed, and has a faulty version of the sound system package installed. For example, to install a package on all VINs starting with “SAJNX5745SC”, and have a revision a2 of the telematics control unit (TCU) base board installed, the following filter could be applied: 
In this case each VIN in the system is checked against the regular expression “SAJNX5745SC??????”. If the examined VIN does match the expression, the filter goes on to check if the component “tcu_base_rev_a2” is installed on the VIN, regardless. Only if the TCU board is installed on a matching VIN will the queued software package be transmitted to the given device. A somewhat more complex example is given below: 
In this case the queued package will only be installed on a VIN if it starts with “SAJNX5745SC”, or the component “IVI_backscreen_rev_*” is installed (regardless of its revision) together with the package “IVI_image” version 1.1.0 – 1.3.9. Please note that the syntax and semantics given in the examples above are suggestions only. Bidders are free to offer other implementations of the filters as long as they are used to identify a subset of managed VINs to transmit and install software packages on. TechnologyThe contractor has a free choice of technology for server- and client-side components, within the constraint that the whole project must be entirely buildable, deployable and executable using Open Source software. The implementation shall employ appropriate technologies that make economical use of computing resources (disk space, memory, CPU, bandwidth). Server deployment environmentThe server-side software shall be delivered as Docker images. The software may be composed of multiple Docker images, in which case the linkage between the images must be documented. Instructions shall be included for deploying the software to a developer machine or to selected CoreOS hosts. The deployed system shall export endpoints for the web interface, the API, and communication with the SOTA clients. All hosting prerequisites and configuration options shall be documented. The Client shall execute on the Genivi Demo Platform (GDP) and the Automotive Grade Linux (AGL) distribution. The hardware platform can be one or more of those supported by GDP and AGL. The latest stable version of the AGL and GDP distributions shall be used during development. The exact versions of AGL and GSP to be supported at the time of project completion are to be determined by the vendor and client before acceptance tests commences. . Deliverables1.5Device-side deliverablesThe SOTA Client work shall be delivered in two separate milestones, resulting in a near production ready system to be adopted for evaluation and pilots by OEMs, Tier-1s, Fleet managers, etc.
The FIRST and INST phase includes a rudimentary SOTA Server that can be used for testing and basic evaluation. The Device side will be complete after FIRST and INST have been delivered, with no further work carried out in the subsequent milestones. Please see Appendix A – Requirement Specification, tabs “FIRST” and “INST” for the formal requirements on the Device deliverables. 1.6Server-side deliverablesThe remaining milestones extends the SOTA Server to near production ready status, yielding a feature-complete, end-to-end SOTA system ready to be deployed in evaluation and pilot programs.
At the end of each server or device milestone the existing code shall be tagged and released. It shall be possible to deploy / demonstrate an end-to-end, functional system at the delivery of each milestone. 1.7Format of deliverablesEach delivery shall include: Source code for SOTA server component (core server, web interface and admin API functionality) Source code for SOTA server test suite Build scripts for creating SOTA server binaries (Dockerfiles or similar) Test scripts for executing SOTA server test suite Binary build of SOTA server for target environment (Docker images) Source code for SOTA client component Source code for SOTA client test suite Build scripts for creating SOTA client binaries (Makefiles or similar) Test scripts for executing SOTA client test suite Binary build of SOTA client component for target environment Complete documentation client and server architecture and implementation, build configuration and execution, test configuration and execution and system deployment Version and licensing information for all project dependencies TestingAny bugs / defects filed against the software during the development period must be resolved before the completion of the project. Bugs / defects include any non-compliance with stated requirements, or any critical instability / functionality / usability issues. Licenses / Intellectual PropertyAll new software created as part of this work shall be licensed under the Mozilla Public License, version 2.0. Where third-party software components are used, they must be available in the public domain or under an open source license which does not preclude commercial exploitation of the work. For example, client-side software shall not include any GPLv3 licensed code and server-side software shall not include any AGPL code. Copyright notices and license information shall be in compliance with the GENIVI Public Policy for Licensing and Copyright: https://collab.genivi.org/wiki/download/attachments/7710652/Public_Policy_for_GENIVI_Licensing_and_Copyright_version_1+6.pdf This work must not infringe any existing patents, and no new patents shall be filed based on components of this implementation. Project ManagementThe project shall be managed through the GENIVI internal issue tracker (JIRA), following the approach below: Weekly or bi‐weekly sprints (to be agreed at project start) Agile development Continuous integration (the software shall be released to the public git as soon as it is available) The contractor team shall coordinate the discussion with the maintainers of GENIVI open source components and the GENIVI SW management topic lead and the AGL EG-RVI lead. The contractor team shall report to the Project Management Office (PMO), who may assign a project manager. Software / Deliverable ManagementThe source code referred to in the “Deliverables” section shall be stored in public GENIVI Git repositories. The GENIVI Alliance shall provide the contractor with read/write permissions to GENIVI repositories. In case the contractor has to contribute patches to a GENIVI Baseline repository, those patches shall be provided through the relevant GENIVI baseline mailing list. Change ManagementGENIVI may request that requirements be adjusted, removed, or introduced during the execution of the project. Contracting partner must respond to all such requests promptly, with an impact assessment (cost / schedule delta). Budget / schedule change requests must be approved by GENIVI. Time ConstraintsThe contractor shall propose a delivery timeline to achieve the described work. The project shall be completed no later than 31st December 2015. Proposal ContentThe proposal shall provide Proposed implementation technology choices A detailed architectural overview, including relationships between software components Expected resource requirements (number of servers, server specification, client requirements) to run a pilot of 100 vehicles. A forecast of effort (man-days, resources required, budget) A schedule overview, including expected delivery dates for each milestone, based on a July 15 2015 project kick-off date. A commitment to give a 1 hour presentation of the project status at the Genivi Fall AMM in Seoul, South Korea, Oct 20-23., The presentation will be held during the AMM Open Days on Oct 21-22. MaintenanceAll bug fixing work required to pass the acceptance tests shall be part of the work described in this document (i.e. it is not a maintenance activity). The contractor shall maintain the developed software in the open source during a period starting at the end of the development until the Spring 2016 GENIVI All Member Meeting. The maintenance work shall consist in reviewing and integrating the patches provided by the community. Appendix A – Requirement SpecificationAppendix A lists all requirements, grouped in worksheets by their components (SRV, WEB, API, etc) The appendix also contains comments which may be useful. Please note that if there are any conflicts between the requirements listed in this document and those listed in Appendix A, Appendix A will take precedence. Appendix A also takes precedence over Appendix B. Appendix B – Use casesAppendix B contains use cases covering the various domains of the SOTA server and the External Resolver. These use cases are informative, not normative, and can be used to gain a better understanding of how the requirements are meant to be interpreted.
Directory: pipermail pipermail -> 1960 Chevrolet Corvair "500" Coupe This Corvair is the pipermail -> Alert newsletter – June 2014 Vol. 7 No. 12 84th Edition pipermail -> Written by Hungarian Women’s Media Lobby and Columbia University students and staff co-operation funded by the Global Fund for Women pipermail -> A. 1 Description of Program a. Executive Summary pipermail -> 10 January 2006 kictanet cocktail Party Appreciating old friends welcoming new ones Jacaranda Hotel, Nairobi 19 January pipermail -> Austron 2000c new gri generator pipermail -> Table of Contents About whois 1 Download 328.3 Kb. Share with your friends:
|