SRV-1 FIRST The system shall use Remote Vehicle Interaction (RVI) for all device communication

SRV-2 FIRST The design implemented by SOTA Server and the Resolver shall be prepared for a production environment in regards to availability and capacity

SRV-3 FIRST The design shall be future expandable with failover sites

SRV-4 FIRST The design shall be future expandable with load sharing across multiple nodes

SRV-5 FIRST The design shall be future expandable with monitoring and alarm management using SNMP, Graphite, or similar

SRV-6 FIRST The design shall be future expandable with backup routines

SRV-7 FIRST The design shall be future expandable with runtime upgrade and downgrade procedures

SRV-VIN-1 SCALE The system shall manage up to 100 million VINs

SRV-VIN-2 FIRST A VIN shall be identified by an 1-64 byte string (VIN). Improved wording

SRV-VIN-3 COMP A VIN shall be able to ber associated to up to 1000 components. Each component is a potential target for software images

SRV-VIN-4 INST Each component associated with a VIN shall have a reference to its currently installed software image.

SRV-VIN-5 INST The component reference to the software image shall be the ID string and version number

SRV-VIN-6 SCALE A VIN shall be able to manage up to 5000 installed software images

SRV-VIN-7 SHAPE The VIN shall be associated with one data plan ID. Ties the VIN to a data plan, allowing us to control traffic to it

SRV-PACKAGE-1 SCALE The system shall manage up to 10 million software packages

SRV-PACKAGE-2 FIRST A software package shall have an ID string

SRV-PACKAGE-3 FIRST A software package shall have a major.minor.patch formatted version number. The ID string plus version is the unique identifier of the package

SRV-PACKAGE-4 FIRST A software package shall have a description

SRV-PACKAGE-5 FIRST A software package shall have a vendor

SRV-PACKAGE-6 COMP The software ID string shall support regexp matching when searching

SRV-PACKAGE-7 COMP The software version number shall support regexp matching when searching

SRV-PACKAGE-8 INST Each software package shall be maintain a list of all VINs it is installed on

SRV-PACKAGE-QUEUE-1 FIRST The system shall be able to request a software package to be installed on a subset of all managed VINs

SRV-PACKAGE-QUEUE-2 SCHED The request shall have an earliest start date. Do not install before 2016-01-01.

SRV-PACKAGE-QUEUE-3 SCHED The request shall have a latest install completion date. Do not install after 2016-04-01

SRV-PACKAGE-QUEUE-4 SCHED If a software package cannot be installed on one ore more targeted VINs within the specified period, they failed VINs shall be logged

SRV-PACKAGE-QUEUE-5 SCHED The request shall have a priority from 1 to 100. Used when updates are queued to individual vehicles. See below

SRV-PACKAGE-QUEUE-6 FIRST A list of currently queued updates shall be maintained. One update consist of one or more software packages targeting a specific VIN.

SRV-PACKAGE-QUEUE-7 FIRST Each queued update shall maintain a list of completed VINs that have received the update

SRV-PACKAGE-QUEUE-8 FIRST Each queued update shall maintain a list of pending VINs that have not yet received the update

SRV-PACKAGE-QUEUE-9 DEPS Each VIN targeted by a queued update shall maintain a list of packages that are rolled into the update for that specvific vin. All packages to be added to original package in order to satisfy dependencies are provided by EXT-RESOLV

SRV-PACKAGE-QUEUE-10 SCHED Updates queued for a specific VIN shall be sorted primarily on ascending request priority. Allows high-priority updates to skip the queue and be pushed out earlier to the vehicle

SRV-PACKAGE-QUEUE-11 FIRST Updates queued for a specific VIN shall be sorted secondarily on the time when the request was made.

SRV-PACKAGE-QUEUE-12 SHAPE The software package install request shall have a data pool usage threshold

SRV-PACKAGE-QUEUE-13 SHAPE The data plan usage threshold shall be specified as a decimal percentage

SRV-PACKAGE-QUEUE-14 SHAPE The data plan usage threshold shall specify the maximum percentage of the data pool assigned to a VIN that can be used when the package transfer starts.

SRV-PACKAGE-QUEUE-15 SHAPE If the data pool associated with a targeted VIN has a usage is greater than the specified threshold for the request, the update for the targeted VIN shall be rescheduled to the next billing cycle.

SRV-PACKAGE-QUEUE-16 SHAPE Updates queued for a specific VIN shall have an individual earliest start date, forcing it to be transmitted within a specific billing cycle. Duplicate of SRV-PACKAGE-QUEUE-2

SRV-PACKAGE-QUEUE-17 SHAPE The individual earliest start date shall not be later than the lastest install completion date specified in SRV-PACKAGE-QUEUE-3

SRV-PACKAGE-QUEUE-18 SHAPE If the update for a specific VIN cannot be rescheduled to a billing cycle before the specified latest install competion date, the update shall fail.

SRV-PACKAGE-QUEUE-19 FIRST The system shall send a resolve package ID to VIN request to the external resolver system in order to retrieve the VINs and dependencies that should have the package installed. See EXT-RESOLV for details

SRV-PACKAGE-QUEUE-20 INST The system shall use EXT-RESOLV-PACKAGE-API to update the resolver with packages installed and removed from each VIN targeted by an update, as reported back by the device. Allows resolver to keep track of which packages are installed on which VIN.

SRV-PACKAGE-QUEUE-21 INST "The system shall be able to queue a ""Get All Installed Packages"" command to a device in order to retrieve its currently installed packages". Used to synchronize Resolver’s list of installed packages on a VIN with reality

SRV-PACKAGE-QUEUE-22 INST "When a ""Get All Installed Packages"" result is received from a device, the EXT-RESOLV-PACKAGE-API shall be used to reset the resolver’s list of installed packages for the given VIN."

SRV-PACKAGE-DEPS-1 DEPS Each VIN, as returned by the external resolver, shall be have a dependency check done for the package that is to be installed

SRV-PACKAGE-DEPS-2 DEPS The depency check shall compare the list of packages already installed on the VIN with the dependency graph of the new package to be installed. Which packages does the package about to be installed need on this specific VIN in order to function.

SRV-PACKAGE-DEPS-3 DEPS If an dependent package, required by the package to be installed, is currently not installed on the VIN, the required package will be added to the update for that specific VIN.

SRV-PACKAGE-DEPS-4 DEPS If installing one or more of the packages in an update on a VIN would break dependencies for packages already installed on that VIN, the update shall fail for the given VIN and be reported back to the server

SRV-PACKAGE-DEPS-5 DEPS A software package shall be dependent on up to 100 other software packages

SRV-PACKAGE-DEPS-6 DEPS Software package depencies shall form a graph of sub dependencies. A requires B, which requires C and D.

SRV-PACKAGE-DEPS-7 DEPS A dependency shall be identified by a software package ID string and a version number

SRV-TRAFFIC-SHAPING-1 ** Server - Device Traffic control and shaping

SRV-TRAFFIC-SHAPING-1 SHAPE The SOTA server shall be manage data plans used to control when updates are to be sent to their targeted VINs

SRV-TRAFFIC-SHAPING-2 SHAPE Up to 1,000 data plans shall be managed by the SOTA server

SRV-TRAFFIC-SHAPING-3 SHAPE A data plan shall specify a system-wide unique a data plan ID

SRV-TRAFFIC-SHAPING-4 SHAPE A single data plan profile shall manage up to 1000 billing cycles . One week billing cycles x 1000 is 20 years of billing

SRV-TRAFFIC-SHAPING-5 SHAPE The data plan shall specify if the data pool for each billing cycle is per VIN, or if it is shared across all VINs associated with the profile. Removed until further notice. For now all billing cycles will be pooled across all VINs

SRV-TRAFFIC-SHAPING-6 SHAPE Each billing cycle shall specify a date and time stamp when it starts

SRV-TRAFFIC-SHAPING-7 SHAPE Each billing cycle shall specify a data pool size in kilobytes

SRV-TRAFFIC-SHAPING-8 SHAPE A billing cycle shall become active when the start date/time stamp occurrs.

SRV-TRAFFIC-SHAPING-9 SHAPE A billing cycle shall be deactivated when the next consecutive billing cycle is activated.

SRV-TRAFFIC-SHAPING-10 SHAPE The SOTA server shall be able to read data usage reports from an external source

SRV-TRAFFIC-SHAPING-11 SHAPE The SOTA server shall deduct data usage from the pool of the currently active billing cycle

SRV-TRAFFIC-SHAPING-12 SHAPE The SOTA server shall at all times know how data is left in a pool at any given time

SRV-TRAFFIC-SHAPING-13 SHAPE When a billing cycle becomes deactive, it shall be archived

SRV-TRAFFIC-SHAPING-14 SHAPE The architved billing cycle shall contain the number of bytes transmitted during the cycle

SRV-TRAFFIC-SHAPING-15 SHAPE Each billing cycle under a data plan shall be shared across all VINs using the given plan. Replaces SRV-TRAFFIC-SHAPING-5

SRV-PACKAGE-TRANSMIT-1 FIRST The Server shall be able to send a wakeup / shoulder tap SMS message to the vehicle, triggering it to connect back to it. Moved from SCHED to FIRST

SRV-PACKAGE-TRANSMIT-2 FIRST When the vehicle connects back and identifies itself all updates queued for the VIN shall be transmitted. Moved from SCHED to FIRST

SRV-PACKAGE-TRANSMIT-3 FIRST The updates shall be transmitted in the order they are sorted. Allows the server to keep track of which packages are installed where

SRV-PACKAGE-TRANSMIT-4 FIRST The update shall be downloadable in chunks. Replaced by SRV-PACKAGE-TRANSMIT-10 - SRV-PACKAGE-TRANSMIT-XXX

SRV-PACKAGE-TRANSMIT-5 FIRST The package transfer shall be restartable in case the data link is interrupted

SRV-PACKAGE-TRANSMIT-6 FIRST The package transfer restart shall continue at the point the transmission was interrupted

SRV-PACKAGE-TRANSMIT-7 INST Once installed on a VIN, an installation acknolwedgement shall be sent back to the SOTA server

SRV-PACKAGE-TRANSMIT-8 INST The installation acknowledgement shall be used to update the association between a VINs components and their installed software packages and versions

SRV-PACKAGE-TRANSMIT-9 INST In case of an installation failure, there shall be an error code and error text returned to the SOTA server. Executes SRC-PACKAGE-QUEUE-22

SRV-PACKAGE-TRANSMIT-10 FIRST "The Server shall send an ""Software Packages Available"" to a vehicle connected for which updates are queued."

SRV-PACKAGE-TRANSMIT-11 FIRST "The ""Software Packages Available"" command shall contain a list of package IDs, descriptive text, and size of the update"

SRV-PACKAGE-TRANSMIT-12 FIRST "The Server shall support an incoming ""Initiate Download"" received from the device."

SRV-PACKAGE-TRANSMIT-13 FIRST "The ""Initiate Software Download"" command shall contain a list of package IDs to send to the device"

SRV-PACKAGE-TRANSMIT-14 FIRST "The Server shall send a ""Start Download"" command to the device to initiate a new download"

SRV-PACKAGE-TRANSMIT-15 FIRST "The ""Start Download"" command shall contain a list of package ID contained in the download, a download index, a file size, a chunk size, a target unit, and an install/upgrade/remove command."

SRV-PACKAGE-TRANSMIT-16 FIRST "The Server shall send ""Package Chunk"" command containing a fragment (chunk) of a package"

SRV-PACKAGE-TRANSMIT-17 FIRST "The ""Package Chunk"" command shall contain a data payload, a chunk index, and an download index refering to the the index provided by the ""Start Download"" command"

SRV-PACKAGE-TRANSMIT-18 FIRST

SRV-PACKAGE-TRANSMIT-19 FIRST "The Server shall support an incoming ""Chunks Received"" command sent by the device"

SRV-PACKAGE-TRANSMIT-20 FIRST "The ""Chunk Received"" shall contain a download index, and a list of successfully received and stored chunks for that package."

SRV-PACKAGE-TRANSMIT-21 FIRST The Server shall inspect the list of successfully received chunks and select as the next chunk to send the lowest indexed chunk not yet received by the device.

SRV-PACKAGE-TRANSMIT-22 FIRST "The Server shall send a ""Finalize Download"" command when a ""Chunks Received"" is received from the device indicating that all chunks have been received and stored."

SRV-PACKAGE-TRANSMIT-23 INST "The ""Finalize Download"" command shall contain a download index."

SRV-PACKAGE-TRANSMIT-24 INST "The Server shall support an incoming ""Installation report"" command sent by the device"

SRV-PACKAGE-TRANSMIT-25 INST "The ""Installation Report"" shall contain a package ID, a status code indicating success or failure, the currently running version of the package, and a descriptive text of the outcome.". Forwarded by SOTA Server to external resolver so that it can keep track of which packages are installed on which VINs

SRV-PACKAGE-TRANSMIT-26 INST The Server shall forward the Installation report to the external resolver. As specified by SRV-PACKAGE-QUEUE-20

SRV-PACKAGE-TRANSMIT-27 FIRST "If a chunk has been sent 5 times, but has not shown up as successfully received in subsequent ""Chunks Received"" reports, the download shall abort."

SRV-PACKAGE-TRANSMIT-28 FIRST "If a chunk has been sent 5 times with no subsequent ""Chunks Received"" command being received at all within a given period of time, the download shall abort."

SRV-PACKAGE-TRANSMIT-29 INST An aborted download shall be reported to thee external resolver

SRV-PACKAGE-TRANSMIT-30 INST "An aborted download shall trigger a ""Abort Download"" command being sent to the device"

SRV-PACKAGE-TRANSMIT-31 INST "An ""Abort Download"" command shall contain the download index of the failed download". Either the device receives it and cancels the download, or the device will time out the download and cancel it.

DEV-1 FIRST The device shall receive and process wakeup / shoulder tap SMS. Please see Appendix B, Use Cases DEV, TRANSFER, and INSTALL_* for a detailed description of protocol flow.

DEV-2 FIRST The device shall, when a shoulder tap SMS is received, connect back to the SOTA server. Moved from SCHED to FIRST

DEV-3 FIRST The device shall identify itself to the SOTA server

DEV-4 FIRST The device shall receive chunks for an update

DEV-5 FIRST The device shall acknolwedge the reception and local storage of each received chunk

DEV-6 FIRST The device shall reassemble the chunks for an update

DEV-7 FIRST The device shall validate the integrity of the update. Will be covered by RVI

DEV-8 FIRST The device shall authenticate the identity of the sender. Will be covered by RVI

DEV-9 FIRST The device shall authorize the sender. Will be covered by RVI

DEV-10 FIRST The device shall interface with the local package manager

DEV-11 INST The device shall report installation success back to the SOTA server. Forwarded by SOTA Server to external resolver so that it can maintain a list of currently installed packages.

DEV-12 INST The device shall report installation failure back to the SOTA server. Installa

DEV-13 INST In case of installation failure, the device shall report an error code and an error text back to the server

DEV-14 INST "The device shall support a ""Get currently installed packages command"" (GetCurrentPackages)". Needed sync up a mismatch between a device’s view of installed packages and that of the backend server.

DEV-15 INST When a GetCurrentPackages command is received, the device shall report back a list of currently installed packages

DEV-16 INST Each package in a report shall be identified by its package ID string and version number

DEV-17 INST There shall be a resend attempt in case reporting of package installation results or currently installed packages fails

DEV-18 INST The device shall, when it connects to the SOTA server, validate the authenticity of the SOTA server. Both client and server side validation are needed.

DEV-19 FIRST The device shall use RVI for all server communication.

DEV-20 FIRST The device software shall execute on top of the latest version of Genivi Demo Platform

DEV-21 FIRST The device software shall execute on top of the latest version of Automotive Grade Linux Distribution

DEV-22 FIRST The device shall interact with the local Genivi Software Loading Manager (GSLM) through DBUS using a protocol supplied by Genivi. Package manager renamed to Genivi Software Loading Manager

DEV-23 FIRST There shall be a DBUS command to send an install command to the local GSLM. Package manager renamed to Genivi Software Loading Manager

DEV-24 FIRST There shall be a DBUS command to send an upgrade command to the local GSLM. Package manager renamed to Genivi Software Loading Manager

DEV-25 FIRST There shall be a DBUS command to send a remove command to the local GSLM. Package manager renamed to Genivi Software Loading Manager

DEV-26 FIRST There shall ba a DBUS command to retrieve a list of all currently installed software from the local GSLM

DEV-27 FIRST All DBUS commands shall return an error/success code and a descriptive text that can be forwarded to SOTA Serevr.

DEV-28 INST The device shall be able to report locally changed software packages to the SOTA Server

DEV-29 INST The device shall receive information about locally changed packages through a DBUS command

DEV-30 INST The report shall contain the package ID, timestamp, and operation (install, upgrade, remove) carried out locally.

DEV-31 FIRST All DBUS commands shall be compliant with call structure of the Genivi Software Loading Manager. Protocol will be specified by Genivi

DEV-32 FIRST The device shall use RVI to communicate with the server

DEV-33 FIRST The device shall use the JSON Data Link and JSON Protocol supplied by the RVI project for its server communication to ensure JSON-based traffic. All traffic sent between server and client will be JSON formatted, regardless of communication channel (SMS, WiFi, 3G, etc). Other protocols (HTTP, OMA-DM FUMA, etc) can be implemented as RVI plugins.

DEV-34 FIRST "The device shall support an incoming ""Software Packages Available"" command received from the server"

DEV-35 FIRST "The ""Software Packages Available"" command shall contain a list of package IDs, descriptive text, and size of the download"

DEV-36 FIRST "The device shall forward the ""Software Packages Available"" command through DBUS to the GSLM ". The Software Loader Manager will interface the HMI to pop a confirmation dialog

DEV-37 FIRST "The device shall support an incoming ""Initiate Download"" received through DBUS from the GSLM.". The user selected one or more packages on the HMI and clicked ok

DEV-38 FIRST "The ""Initiate Software Download"" command shall contain a list of package IDs to download and install". "Package IDs are selected from those provided by the ""Software Packages Available"""

DEV-39 FIRST "The ""Initiate Software Download"" command received from the GSLM shall be forwarded to the SOTA server to initiate the download.". "Will result in a ""Start Download"" command being sent from the Server"

DEV-40 FIRST "The device shall support an incoming ""Start Download"" command to initiate a new download"

DEV-41 FIRST "The ""Start Download"" command shall contain a list of package ID contained in the download, a download index, a file size, a chunk size, a target unit, and an install/upgrade/remove command.". "Multple packages may be contained in a single download. Packages can either be dependencies, or bundled packages from the ""Initiate Software Download"" package. Target tells the GSLM if this is a local package, or if it is destined for a module managed by the Module Loader."

DEV-42 FIRST "The device shall support an incoming ""Package Chunk"" command containing a fragment (chunk) of a package"

DEV-43 FIRST "The ""Package Chunk"" command shall contain a data payload, a chunk index, and an download index refering to the the index provided by the ""Start Download"" command". "Download index allows multiple donwloads to happen in parallell. payload size is specified by chunk size in ""Start Download"""

DEV-44 FIRST The device shall store each received chunk on in secondary storage. Downloaded images are reassembled, chunk by chunk on the device side.

DEV-45 FIRST "The device shall send a ""Chunks Received"" report back to the SOTA Server"

DEV-46 FIRST "The ""Chunk Received"" shall contain a download index, and a list of successfully received and stored chunks for that package.". [1-10,12-15,21,23,25,27-30]

DEV-47 FIRST "The ""Chunk Received"" command shall be sent at after ""Package Chunk"" command has been successfully stored.". Overkill, but increases robustness.

DEV-48 FIRST "The device shall support an incoming ""Finalize Download command to finish the download". "Will only be sent when ""Chunks received"" reports that all chunks have been received."

DEV-49 FIRST "The ""Finalize Download"" command shall contain a download index.". Clears the device to start the installation process.

DEV-50 FIRST The device shall verify that all chunks have been received when a download is finalized.

DEV-51 FIRST The device shall verify the source and authenticity of the download

DEV-52 FIRST If either verification fails, an install failure shall be sent back to the SOTA server for all Package IDs in the download

DEV-53 FIRST "The device shall forward the finalized download to the GSLM together with the install/upgrade/remove command and target unit specified in the ""Start Download"" command.". Commands to be sent are specified by DEV-23 - DEV-27

DEV-54 INST "The device shall support an incoming DBUS ""Installation Report' command from the local GSLM."

DEV-55 INST "The ""Installation Report"" shall contain a package ID, a status code indicating success or failure, the currently running version of the package, and a descriptive text of the outcome.". The running version can either be the new version, the existing version, or a reverted factory version.

DEV-56 INST The device shall forward the installation report to the SOTA Server. SOTA Server will forward it to the external resolver, allowing it to maintain its database of installed packages.

DEV-57 INST "If no additional ""Package Chunks"" are received for an ongoing download within a given timeout period, the download shall abort"

DEV-58 INST "If a ""Start Download"" command is received with a download index equal to that of an ongoing download, the ongoing download shall be aborted to make way for the new download.". Allows timed out downloads to be restarted.

DEV-59 INST "The device shall support an incoming ""Abort Download"" command "

DEV-60 INST "The ""Abort Download"" command shall contain the download index"

DEV-61 INST An aborted download shall delete any stored data on the device.

DEV-62 INST "If the download index of an ""Abort Download"" command cannot be found, the command shall silently be ignored.". """Start Download"" command was lost and never received by client"

API-1 FIRST The Server shall support an API, allowing its functionality to be accessed by external apps and services

API-2 FIRST The API shall be based on Restful HTTP with JSON.bodies

API-VIN-1 FIRST The API shall have a command to add VINs

API-VIN-2 FIRST The API shall have a command to delete VINs

API-VIN-3 FIRST The API shall have a call to search for and return VINs using regexp wildcards. Duplicate of API-VIN-7 - 8

API-VIN-4 COMP The API shall have a call to associate a component to an existing VIN. Moved to Resolver

API-VIN-5 INST The API shall have a call to associate an software image to a VIN. Moved to Resolver

API-VIN-6 INST The software image associated with a VIN shall be associated with a specific component installed on that VIN. Removed association between package and specific component. Packages are now generically installed on a VIN without component association.

API-VIN-7 FIRST The API shall have a VIN search command

API-VIN-8 FIRST The search command shall support a VIN regexp to match against

API-VIN-9 COMP The VINs returned by the search shall each have their associated components listed. Moved to Resolver

API-VIN-10 INST The VINs returned by the search shall each have their associated installed software packages listed

API-VIN-11 INST The API shall have a command to list all historic package updates sent to a VIN since the VIN was created

API-VIN-12 INST Each update returned by a historic list command shall contain a result code reflecting success or failure of installing the package

API-VIN-13 INST Each update returned by a historic list command shall contain all dependent-upon packages transmitted with the original package in order to satisfy all dependencies of the installed package

API-VIN-14 INST Each update returned by a historic list command shall contain a time stamp of when the update completed or failed

API-PACKAGE-1 FIRST The API shall have a command to upload packages to the system

API-PACKAGE-2 FIRST Each package shall have an ID string specified

API-PACKAGE-3 FIRST Each package shall have a version number specified so that ID string plus version number creates a unique queue.

API-PACKAGE-4 DEPS Each package shall have an optional list of dependencies specified. Moved to resolver

API-PACKAGE-5 FIRST The API shall have a command to list search for software packages

API-PACKAGE-6 FIRST The search command shall support regexp matching for the ID string and the version number

API-PACKAGE-7 INST The API shall have a command to list all the VINs that a specific version of a software package is installed on. Database of which packages are installed on which VIN now handled by resolver

API-PACKAGE-8 INST The API shall have a command to list all the VINs that a specific version of a software package is queued for installation on. Duplicate of API-QUEUE-7

API-PACKAGE-9 DEPS The API shall have a command to list the dependencies for a specific package. Moved to resolver

API-QUEUE-1 FIRST The API shall have a command to request that an package is to be installed

API-QUEUE-2 FIRST The install command shall provide a filter label to be applied to the request. Not necessary with external resolver

API-QUEUE-3 FIRST The install command shall return a unique install ID for the install request

API-QUEUE-4 SCHED The API shall have a command to cancel a previously queued install request

API-QUEUE-5 SCHED Canceling an install request will delete any pending updates that have yet to be transmitted to their targeted VINs.

API-QUEUE-6 SCHED Canceling an install request shall not affect any packages already installed on their targeted VINs.

API-QUEUE-7 SCHED The API shall have a command to list all VINs targeted by a specific install request, identified by the install ID

API-QUEUE-8 SCHED The list command shall return all VINs which the install request was successfully completed on

API-QUEUE-9 SCHED The success report for a VIN shall include a date and time stamp.

API-QUEUE-10 SCHED The list command shall return all VINs for which the install request is still pending on the server

API-QUEUE-11 SCHED The list command shall return all VINs for which the install request failed

API-QUEUE-12 SCHED The failure report for a VIN shall include a date and time stramp.

API-QUEUE-13 SCHED The failure report for a VIN shall include a reason code such as time out, dependency failure, etc.

API-QUEUE-14 SCHED The failure report for a VIN shall include a reason text.

API-QUEUE-15 SCHED The list command shall, for each returned VIN, list the software packages included in the update, including dependencies

API-QUEUE-16 SCHED The list command shall return all VINs for which the install request has started transmission, but has not yet completed

API-QUEUE-17 FIRST "The API shall have a command to queue an ""Get All Installed Packages"" command for a given VIN"

API-TRAFFIC-SHAPING-1 SHAPE The API shall have a command to add a data plan

API-TRAFFIC-SHAPING-2 SHAPE The added data plan shall have a unique data plan ID

API-TRAFFIC-SHAPING-3 SHAPE The added data plan shall specify if the billing cycles' data pools are shared across all VIN or is specified per VIN. All plans will be pooled across all VINs for now

API-TRAFFIC-SHAPING-4 SHAPE The API shall have a command to delete an existing data plan and its billing cycles. Not necessary at a first implementation

API-TRAFFIC-SHAPING-5 SHAPE The API shall have a command to add a billing cycle to an existing data plan

API-TRAFFIC-SHAPING-6 SHAPE The added billing cycle shall have a start date and time stamp

API-TRAFFIC-SHAPING-7 SHAPE The added billing cycle shall have a data pool size, specified in kilobytes.

API-TRAFFIC-SHAPING-8 SHAPE The billing cycle shall be identified by its associated data plan and start date/time stamp.

API-TRAFFIC-SHAPING-9 SHAPE The API shall have a command to delete an existing billing cycle. Not necessary at a first implementation

API-TRAFFIC-SHAPING-10 SHAPE The API shall have a command to add transmitted bytes to the currently active billing cycle of a specific data plan. Increases usage of the given billing cycle

API-TRAFFIC-SHAPING-11 SHAPE The API shall have a command to retrieve the data pool size of the current billing cycle of a specific data plan

API-TRAFFIC-SHAPING-12 SHAPE The API shall have a command to retrieve the number of used bytes in the current billing cycle of a specific data plan

API-TRAFFIC-SHAPING-13 SHAPE The API shall have a command to list all billing cycles created under a data plan

WEB-1 FIRST The web system shall act as a front end toward the SOTA system

WEB-2 FIRST The web system shall use the Web API of the SOTA system

WEB-3 SCALE The web system shall have a provisioning system for adding users

WEB-4 SCALE The web system shall have a provisioning system for deleting users

WEB-5 SCALE Each user shall have a username

WEB-6 SCALE Each user shall have a password

WEB-7 SCALE The web system shall have a pre-configured admin user with a pre-configured password.

WEB-8 SCALE Only the admin user shall be able to add and delete other users

WEB-9 SCALE All users in the system shall have full access to all web functions, except add/delete users. For now. Different access levels will come later.

WEB-VIN-1 FIRST The web system shall have a UI to add VINs

WEB-VIN-2 SCHED The web system shall have a UI to delete VINs

WEB-VIN-3 SCHED The web system shall have a UI to search for VINs

WEB-VIN-4 SCHED The web system’s VINs shall be searchable by regular expressions

WEB-VIN-5 SCHED Each VIN by a search shall be clickable

WEB-VIN-6 SCHED Clicking on a VIN from the search result shall bring up a property screen for the VIN

WEB-VIN-7 COMP The VIN property screen shall list all components installed on the VIN, as retrieved from the external resolver

WEB-VIN-8 INST Each component on a VIN property screen shall be listed with its currently installed software image and version. Packages no longer associated with target components on a VIN.

WEB-VIN-9 INST The VIN property screen shall list all installed software packages (including dependencies), as retrieved from the external resolver

WEB-VIN-10 COMP The VIN property screen shall have a button for adding a component on the external Resolver. Duplicate of WEB-RESOLV-COMP-1

WEB-VIN-11 COMP Adding a component shall specify the component part number. Duplicate of WEB-RESOLV-COMP-1

WEB-VIN-12 INST The VIN property screen shall have a button for adding a (manually installed) software package on a VIN. API Call sent to the Resolver

WEB-VIN-13 INST The software package added to the system shall be specified with a ID string

WEB-VIN-14 INST The software package added to the system shall be specified with a version number

WEB-VIN-15 INST The software package added to the system shall be specified with a description

WEB-VIN-16 INST The software package shall be assocaited with a component installed on the VIN. Packages no longer associated with target components on a VIN.

WEB-VIN-17 INST The VIN property screen shall have a button to list all software packages currently queued to it

WEB-VIN-18 FIRST A VIN added, deleted, or modified by the web system shall update both the server and the external resolver

WEB-VIN-19 INST The VIN property screen shall have a button to re-synchronize the list of installed packages with those actually installed on device

WEB-PACKAGE-1 FIRST The web system shall have a UI to upload packages to the system.

WEB-PACKAGE-2 FIRST The upload screen shall have a software package ID string

WEB-PACKAGE-3 FIRST The upload screen shall have a software version

WEB-PACKAGE-4 FIRST The upload screen shall have a description

WEB-PACKAGE-5 FIRST The upload screen shall have a vendor

WEB-PACKAGE-6 DEPS The upload screen shall allow to specify dependencies on one or more exisiting software packages. Interfaces resolver to handle dependencies

WEB-PACKAGE-7 FIRST The web system shall have a UI to search for software packages

WEB-PACKAGE-8 FIRST The search command shall support regexp matching for the ID string and the version number

WEB-PACKAGE-9 FIRST Each software package in the returned search result list shall be clickable

WEB-PACKAGE-10 FIRST Clicking on an package from the search result shall bring up a property screen for the package

WEB-PACKAGE-11 FIRST The package property screen shall show the package ID string

WEB-PACKAGE-12 FIRST The package property screen shall show the version number

WEB-PACKAGE-13 FIRST The package property screen shall show the description

WEB-PACKAGE-14 FIRST The package property screen shall show the vendor

WEB-PACKAGE-15 DEPS The package property screen shall show all the software package dependencies the shown package has. Interfaces resolver to handle dependencies

WEB-PACKAGE-16 INST The package property screen shall have a button to list all VINs that the package is installed on. Interfaces resolver to retrieve lsit

WEB-PACKAGE-17 INST Clicking on the installed VIN button shall bring up a list of all VINs with the package installed

WEB-PACKAGE-18 INST The package property screen shall have a button to list all VINs that the package is queued for

WEB-PACKAGE-19 FIRST A package added, deleted, or modified by the web system shall update both the server and the external resolver

WEB-PACKAGE-20 FIRST The package property screen shall have a button to list all filters that will be executed when the package is resolved to VINs. "Will queue a ""Get All Installed Packages"" command to the given VIN, using API-QUEUE-17"

WEB-QUEUE-1 FIRST The web system shall have a user interface for creating an update to be pushed to one or more VINs

WEB-QUEUE-2 FIRST The create update screen shall specify the software package and version to push

WEB-QUEUE-3 FIRST The create update screen shall specify the filter tag to apply. Not applicable with external resolver

WEB-QUEUE-4 SCHED The create update screen shall specify the earliest start date for the update to be installed

WEB-QUEUE-5 SCHED The create update screen shall specify the latest end date for the update to be installed

WEB-QUEUE-6 SCHED The create update screen shall specify a priority

WEB-QUEUE-7 FIRST The create update screen shall have a button to contact external resolver and list all VINs that would receive the update. Will invoke external resolver to map package ID to VINs

WEB-QUEUE-8 FIRST The web system shall have a user interface to list all created updates in the system

WEB-QUEUE-9 FIRST Each listed update shall be shown with its software package and filter label

WEB-QUEUE-10 FIRST Each listed update shall be clickable

WEB-QUEUE-11 FIRST Clicking on the update shall bring up the update property screen

WEB-QUEUE-12 FIRST The update property screen shall show the information provided by WEB-QUEUE-[2-6]

WEB-QUEUE-13 FIRST The update property screen shall show the total number of VINs targeted by the update

WEB-QUEUE-14 INST The update property screen shall show the total number of VINs that have had the update successfully installed

WEB-QUEUE-15 INST The update property screen shall show the total number of VINs that have failed to have the update installed

WEB-QUEUE-16 INST The update property screen shall show the total number of VINs that are still waiting to receive the update

WEB-QUEUE-17 INST The update property screen shall be able to list all VINs that have had the update succsessfully installed

WEB-QUEUE-18 INST The update property screen shall be able to list all VINs that failed to have the update installed

WEB-QUEUE-19 FIRST The update property screen shall be able to list all VINs that are still waiting to recveive the update

WEB-QUEUE-20 FIRST Each VIN listed in WEB-QUEUE-[17-19] shall be clickable

WEB-QUEUE-21 COMP Clicking on a VIN shall list all software packages and version included in the update for the given VIN

WEB-QUEUE-22 SCHED "The update property screen shall have a ""cancel update"" button."

WEB-QUEUE-23 SCHED "Clicking on the ""cancel update"" button shall cancel any updates to VINs that are not yet complete"

WEB-QUEUE-24 SCHED "Clicking on the ""cancel update"" button shall delete the update itself."

WEB-TRAFFIC-SHAPING-1 SHAPE The web system shall have a user interface to add a data plan

WEB-TRAFFIC-SHAPING-2 SHAPE The add data plan screen shall have a unique data plan ID

WEB-TRAFFIC-SHAPING-3 SHAPE The add data plan screen shall specify if the data pool size is per VIN or is shared across all participating VINs. Not needed in a first implenentation

WEB-TRAFFIC-SHAPING-4 SHAPE The add data plan shall have a command to delete an existing data plan and its billing cycles. Was previously erroneously removed instead of the line above.

WEB-TRAFFIC-SHAPING-5 SHAPE The web system shall have a user interface to add billing cycles to a data plan

WEB-TRAFFIC-SHAPING-6 SHAPE An added billing cycle shall be entered with a start date / time stamp

WEB-TRAFFIC-SHAPING-7 SHAPE An added billing cycle shall be entered with a data pool size in kilobytes

WEB-TRAFFIC-SHAPING-8 SHAPE The web system shall be able to list all data plans and their properties

WEB-TRAFFIC-SHAPING-9 SHAPE The web system shall be able to list all billing cycles added to a data plan and their properties

WEB-TRAFFIC-SHAPING-10 SHAPE The web system shall be able to delete an existing billing cycle under a data plan. Not needed in a first implementation

WEB-TRAFFIC-SHAPING-11 SHAPE The web system shall be able to show the current data pool usage for an existing billing cycle

WEB-TRAFFIC-SHAPING-12 SHAPE The web system shall be able to update the data pool usage for an existing billing cycle by setting a kilobyte value

WEB-RESOLV-FILTER-1 FIRST The web system shall have a user interface for adding install filters on the external resolver

WEB-RESOLV-FILTER-2 FIRST The add install filter screen shall have a filter label

WEB-RESOLV-FILTER-3 FIRST The add install filter screen shall have a text field for a boolean expression

WEB-RESOLV-FILTER-4 FIRST The add install filter screen shall have a button to syntax check the boolean expression

WEB-RESOLV-FILTER-5 FIRST In case the syntax check fails, an error code and text should be showed

WEB-RESOLV-FILTER-6 FIRST The web system shall have a button to list all filters on the external resolver

WEB-RESOLV-FILTER-7 FIRST Each filter returned in the list result shall be clicklable

WEB-RESOLV-FILTER-8 FIRST Clicking on a filter in the list result shall bring up the filter property screen retrieved from the external resolver

WEB-RESOLV-FILTER-9 FIRST The property screen shall be able to edit all filter properties

WEB-RESOLV-FILTER-10 FIRST The property screen shall support syntax checking of changed boolean expression

WEB-RESOLV-FILTER-11 FIRST "The property screen shall have a ""delete filter"" to remove a filter from the external resolver"

WEB-RESOLV-FILTER-12 FIRST "The property screen shall have a ""list associated packages"" to list all packages that will have the filter executed when resolved"

WEB-RESOLV-FILTER-13 FIRST The property screen shall be able to add a filter to a package. The filter(s) associated with a package will be run over all VINs when the given package is resolved.

WEB-RESOLV-FILTER-14 FIRST The property screen shall be able to delete a filter from a package

WEB-RESOLV-COMP-1 COMP The web system shall have a UI to add components to the external resolver using a component part number

WEB-RESOLV-COMP-2 COMP The web system shall have a UI to delete components from the external resolver

WEB-RESOLV-COMP-3 COMP The web system shall have a UI to search for components in the external resolver

WEB-RESOLV-COMP-4 COMP The web system’s components shall be searchable by part number regular expressions

WEB-RESOLV-COMP-5 COMP The componens returned by a search shall be clickable

WEB-RESOLV-COMP-6 COMP Clicking on a component from the search result shall bring up a property screen for the component

WEB-RESOLV-COMP-7 COMP The component property screen shall show the part number

WEB-RESOLV-COMP-8 COMP The component property screen shall show the description

WEB-RESOLV-COMP-9 COMP The component property screen shall have a button to list all VINs that the component is installed on

WEB-RESOLV-COMP-10 COMP The web system shall have a UI to add a component to a specific VIN using the external resolver.

EXT-RESOLV ** External package to VIN resolver

EXT-RESOLV-1 FIRST The system shall rely on an external system, the Resolver, to translate a software package to VINs that are to have the package installed.

EXT-RESOLV-2 FIRST The resolver shall have a server-side WebAPI to handle resolve requests.

EXT-RESOLV-3 FIRST A resolve request, sent to the external resolver by the system, shall contain a software package ID string.

EXT-RESOLV-4 FIRST A resolve request shall return a list of zero or more VIN numbers that the sofware package should be installed on

EXT-RESOLV-API-1 FIRST The Resolver shall support an API, allowing its functionality to be accessed by external apps and services

EXT-RESOLV-API-2 FIRST The API shall be based on Restful HTTP with JSON.bodies

EXT-RESOLV-FILTER-1 FIRST A resolve request shall retrieve the VINs to install an package on by executing one or more filters

EXT-RESOLV-FILTER-2 FIRST A single filter shall be associated with zero or more software package IDs

EXT-RESOLV-FILTER-3 FIRST The software package ID string of a resolve request shall be used retrieve the all filters associated with the package ID.

EXT-RESOLV-FILTER-4 FIRST Each filter retrieved for an package ID in a resolve request shall be run on all VINs in order to filter out those VINs that should receive the update. All filters are AND-ed together.

EXT-RESOLV-FILTER-5 FIRST Only VINs that pass all filters associated with the software package ID shall be returned by the resolve request

EXT-RESOLV-FILTER-6 FIRST The filter shall specify a boolean expression that has to be true for a specific VIN in order for the software package to be queued to that VIN.

EXT-RESOLV-FILTER-7 COMP The boolean expression shall have operands that identify specific components by their part number

EXT-RESOLV-FILTER-8 COMP The component part number in the expression shall support regexp matching

EXT-RESOLV-FILTER-9 INST The boolean expression shall have operands that identify the currently installed packages packages.

EXT-RESOLV-FILTER-10 INST The currently installed package is identified by its ID string and version number

EXT-RESOLV-FILTER-11 INST The ID string and version number of the currently installed package shall support regexp matching

EXT-RESOLV-FILTER-12 FIRST The VIN operand shall support regexp matching

EXT-RESOLV-FILTER-13 FIRST The finished boolean expression shall be labeled and stored as a named, reusable filter

EXT-RESOLV-FILTER-API-1 FIRST The API shall have a command to add new filters

EXT-RESOLV-FILTER-API-2 FIRST The added filter shall have a boolean expression

EXT-RESOLV-FILTER-API-3 FIRST The added filter shall have a unique label

EXT-RESOLV-FILTER-API-4 FIRST The API shall havea a command to check the syntax of a boolean expression

EXT-RESOLV-FILTER-API-5 FIRST The syntax check shall return ok or an error code and text

EXT-RESOLV-FILTER-API-6 COMP The API shall have a command to delete filters identified by their label

EXT-RESOLV-FILTER-API-7 FIRST The API shall have a command to associate a package ID string to a filter. Used during resolve package → VINs to figure out which filter to apply to th egiven VINs

EXT-RESOLV-FILTER-API-8 FIRST The API shall have a command to dis-associate a package ID string from a filter

EXT-RESOLV-FILTER-API-9 FIRST The API shall have a command to list all filters associated with a package ID string

EXT-RESOLV-FILTER-API-10 FIRST The filters associated with the given package ID shall have their filter labels returned

EXT-RESOLV-FILTER-API-11 FIRST The API shall have a command to list all packages associated with a filter label.

EXT-RESOLV-FILTER-API-12 FIRST The packages associated with the given filter label shall have their package ID strings returned.

EXT-RESOLV-VIN-1 SCALE The resolver shall manage up to 100 million VINs

EXT-RESOLV-VIN-2 FIRST A VIN shall use a VIN number as its primary identifier

EXT-RESOLV-VIN-3 COMP A VIN shall be able to ber associated to up to 1000 components

EXT-RESOLV-VIN-4 INST A VIN shall be able to handle up to 5000 installed software packages

EXT-RESOLV-VIN-API-1 FIRST The API shall have a command to add VINs

EXT-RESOLV-VIN-API-2 FIRST The API shall have a command to delete VINs

EXT-RESOLV-VIN-API-3 COMP The API shall have a call to specify a component has been installed in an VIN

EXT-RESOLV-DEPS-1 DEPS Each VIN returned by a resolver for a specific package shall have a dependency check done for that package

EXT-RESOLV-DEPS-2 DEPS The depency check shall compare the list of packages already installed on the VIN with the dependency graph of the new package to be installed Which packages does the package about to be installed need on this specific VIN in order to function.

EXT-RESOLV-DEPS-3 DEPS If an dependent package, required by the package to be installed, is currently not installed on the VIN, the required package will be provided with the given VIN when returned to the SOTA Server.

EXT-RESOLV-DEPS-4 DEPS If installing one or more of the packages in an update on a VIN would break dependencies for packages already installed on that VIN, an error will be logged for the given update by the resolver and the VIN is removed from the set of VINs returned by the resolver

EXT-RESOLV-DEPS-5 DEPS A software package shall be dependent on up to 100 other software packages

EXT-RESOLV-DEPS-6 DEPS Software package depencies shall form a graph of sub dependencies. A requires B, which requires C and D.

EXT-RESOLV-DEPS-7 DEPS A dependency shall be identified by a software package ID string and a version number

EXT-RESOLV-DEPS-API-1 DEPS The resolver shall have a command to add a dependency from one package toward another

EXT-RESOLV-DEPS-API-2 DEPS The resolver shall have a command to delete a dependency from one package toward another

EXT-RESOLV-DEPS-API-3 DEPS The resolver shall have a command to list all dependencies of a package. Can be called recursively to get entire dependency graph

EXT-RESOLV-COMP-1 COMP The resolver system shall manage up to 1 million components. Used by filtering process to require that specific components are installed in order for a package to be installed

EXT-RESOLV-COMP-2 COMP A component has a part number. Main identifier used by software packages.

EXT-RESOLV-COMP-3 COMP A component has a description

EXT-RESOLV-COMP-4 COMP A component can have one or more VINs associated with it. Each VIN has zero or more components installed on it.

EXT-RESOLV-COMP-API-1 COMP The API shall have a command to add a component to the system with a part number

EXT-RESOLV-COMP-API-2 COMP The API shall have a command to specify that a component is installed on a specific VIN. "Will make has_component(""xxx"") return true in a filter run over the given VIN."

EXT-RESOLV-COMP-API-3 COMP The API shall have a command to search for and return components using regexp wildcards

EXT-RESOLV-COMP-API-4 COMP The returned components shall be listed with their part number

EXT-RESOLV-COMP-API-5 COMP The returned components shall be listed with their descriptions

EXT-RESOLV-COMP-API-6 COMP The API shall have a command to list all VINs that a component is installed on

EXT-RESOLV-PACKAGE-1 SCALE The resolver shall manage up to 10 million software packages

EXT-RESOLV-PACKAGE-2 FIRST A software package shall have an ID string

EXT-RESOLV-PACKAGE-3 FIRST A software package shall have a major.minor.patch formatted version number. The ID string plus version is the unique identifier of the package

EXT-RESOLV-PACKAGE-4 FIRST A software package shall have a description

EXT-RESOLV-PACKAGE-5 FIRST A software package shall have a vendor

EXT-RESOLV-PACKAGE-6 INST Each software package shall be maintain a list of all VINs it is installed on. Used by filter has_package() operand

EXT-RESOLV-PACKAGE-API-1 FIRST The API shall have a command to specify a package to the external resolver

EXT-RESOLV-PACKAGE-API-2 FIRST Each package shall have an ID string specified

EXT-RESOLV-PACKAGE-API-3 FIRST Each software package shall have a major.minor.patch formatted version number. The ID string plus version is the unique identifier of the package

EXT-RESOLV-PACKAGE-API-4 FIRST Each package shall have a version number specified so that ID string plus version number creates a unique queue.

EXT-RESOLV-PACKAGE-API-5 INST The resolver shall have a command to specify that a given package has been installed on a VIN. Called by the SOTA Server when a device reports that an update has been installed.

EXT-RESOLV-PACKAGE-API-6 INST The resolver shall have a command to specify that a given package has been deleted from a VIN. Called by the SOTA Server when a device reports that an update has been updated/removed

EXT-RESOLV-PACKAGE-API-7 INST The resolver shall have a command to search for all packages installed on a VIN

EXT-RESOLV-PACKAGE-API-8 INST The resolver shall have a command to search for all VINs that a package is installed on.

SRV-CAPACITY-1 SCALE The system shall support a cold standby

SRV-CAPACITY-2 SCALE The system shall provide 99.9% uptime, yielding a maximum of 43.8 minutes downtime per month.

SRV-CAPACITY-3 SCALE The uptime includes maintenance, upgrades, backup, and other administrative routines

SRV-CAPACITY-4 SCALE The system shall handle a load capacity of 200 chunks of package data being transmitted per second to vehicles

SRV-CAPACITY-5 SCALE Each chunk shall be 100KBytes, rendering the total chunking bandwidth to 20MByte/Sec.

SRV-CAPACITY-6 SCALE The system shall queue at least 100 packages per seconds to their target VINs

SRV-CAPACITY-7 SCALE The target VINs shall be selected from a fleet of 1,000,000 VINs.

SRV-CAPACITY-8 SCALE The VINs filtered out by a queueing operation shall be 100,000, rendering the total queuing time to 1000 seconds for all targbeted VINs

SRV-CAPACITY-9 SCALE At no time shall transactional latency be greater than 500 msec.

SRV-CAPACITY-10 SCALE Transactional latency is defined as the number of milliseconds elasped from that the transaction was read from the NIC to the time the result was sent back over the NIC.

SRV-CAPACITY-11 SCALE A transaction is defined as a request sent from either a vehicle, an external system, or the Web UI to the system

SRV-CAPACITY-12 SCALE SRV-CAPCITY-4 to SRV-CAPACITY-11 shall be handled in parallel.

SRV-CAPACITY-13 SCALE SRV-CAPACITY-1 - 12 applies both to the server and the external resolver.

SRV-BACKUP-1 SCALE The system shall have backup routines

SRV-BACKUP-2 SCALE The backup shall be documented as a part of the maintenance instructions

SRV-BACKUP-3 SCALE A freshly installed SOTA system with the backup applied shall render a system identical to the originally backed up system

SRV-BACKUP-4 SCALE The backup system shall be able to selectively restore only VINs in both the external Resolver and the Server. Modifed wording to cover both resolver and system

SRV-BACKUP-5 SCALE The backup system shall be able to selectively restore only components in both the external Resolver and the server. Modifed wording to cover both resolver and system

SRV-BACKUP-6 SCALE The backup system shall be able to selectively restore only packages

SRV-BACKUP-7 SCALE The backup system shall be able to selectively restore only the package queues and package transmission status

SRV-BACKUP-8 SCALE The backup system shall be able to selectively restore only data plans and billing cycles

SRV-BACKUP-9 SCALE The backup system shall be able to selectively restore only filters

SRV-BACKUP-10 SCALE SRV-BACKUP-1 - 10 applies both to the server and the external resolver.

SRV-UPGRADE-1 SCALE The system shall be upgradable.

SRV-UPGRADE-2 SCALE The upgrade shall support a rollback to its previous state

SRV-UPGRADE-3 SCALE The upgrade shall be done with no uptime impact.

SRV-UPGRADE-4 SCALE The upgrade can be done with capacity degradation if, for example, one side of a cluster is upgraded at the time. Negative requirement. Removed.

SRV-UPGRADE-5 SCALE The capacity during an upgrade shall at all times stay above 40% of the whole system’s capacity.

SRV-UPGRADE-6 SCALE SRV-UPGRADE-1 - 5 applies both to the server and the external resolver.

SRV-LOGGING-1 SCALE The system shall support logging.

SRV-LOGGING-2 SCALE Logging shall have at least 5 different log levels.

SRV-LOGGING-3 SCALE Log levels shall be settable while the system is running

SRV-LOGGING-4 SCALE Logs shall rotate so that they never consume more than a given amount of disk space

SRV-LOGGING-5 SCALE The amount of disk space consumed by logs shall be settable while the system is running

SRV-LOGGING-6 SCALE SRV-LOGGING-1 - 5 applies both to the server and the external resolver.

SRV-MON-1 SCALE The system shall be monitorable via SNMP, graphite, or similar open standard

SRV-MON-2 SCALE All SRV-MON requirements above and below applies both to the server and the extrernal resolver.

SRV-MON-ALARM-1 SCALE Monitoring shall provide alarms

SRV-MON-ALARM-2 SCALE Alarms shall be triggered by resource exhaustion

SRV-MON-ALARM-3 SCALE Alarms shall be triggered by software component failures and restarts

SRV-MON-ALARM-4 SCALE Alarms shall be triggered by excessive latency

SRV-MON-ALARM-5 SCALE Alarms shall be triggered by failed external systems such as provisioning

SRV-MON-ALARM-6 SCALE Alarms shall be triggered by hardware failures

SRV-MON-ALARM-7 SCALE Alarms shall be manually acknolwedged by an operator action

SRV-MON-COUNT-1 SCALE Monitoring shall provide counters

SRV-MON-COUNT-2 SCALE Counters shall be persistent across system restarts

SRV-MON-COUNT-3 SCALE Counters shall be kept for number of transactions processed by the system

SRV-MON-COUNT-4 SCALE Counters shall be kept for number of packages sent to vehicles

SRV-MON-COUNT-5 SCALE Counters shall be kept for number of kilobytes sent to vehicles

SRV-MON-COUNT-6 SCALE Counters shall be kept for number of kilobytes received from vehicles

SRV-MON-COUNT-7 SCALE Counters shall be kept for number of sessions from vehicles

SRV-MON-GAUGE-1 SCALE Monitoring shall provide gauges

SRV-MON-GAUGE-2 SCALE Each gauge shall provide an average value over the last 10 seconds

SRV-MON-GAUGE-3 SCALE Each gauge shall provide an average value over the last 60 seconds

SRV-MON-GAUGE-4 SCALE Each gauge shall provide an average value over the last 600 seconds

SRV-MON-GAUGE-5 SCALE Each gauge shall provide an average value over the last 3600 seconds

SRV-MON-GAUGE-6 SCALE Each gauge shall provide an average value over the last 86400 seconds

SRV-MON-GAUGE-7 SCALE Each gauge shall provide a min and max measured value over the last 10 seconds

SRV-MON-GAUGE-8 SCALE Each gauge shall provide a min and max measured value over the last 60 seconds

SRV-MON-GAUGE-9 SCALE Each gauge shall provide a min and max measured value over the last 600 seconds

SRV-MON-GAUGE-10 SCALE Each gauge shall provide a min and max measured value over the last 3600 seconds

SRV-MON-GAUGE-11 SCALE Each gauge shall provide a min and max measured value over the last 86400 seconds

SRV-MON-GAUGE-12 SCALE Monitoring shall gauge transactions per second

SRV-MON-GAUGE-13 SCALE Monitoring shall gauge transactional latency

SRV-MON-GAUGE-14 SCALE Monitoring shall gauge disk consumption

SRV-MON-GAUGE-15 SCALE Monitoring shall gauge virtual memory consumption

SRV-MON-GAUGE-16 SCALE Monitoring shall gauge bytes/second transmitted to all vehicles

SRV-MON-GAUGE-17 SCALE Monitoring shall gauge bytes/second transmitted from all vehicles

SRV-1 The system shall use Remote Vehicle Interaction (RVI) for all device communication

SRV-2 The design implemented by SOTA Server and the Resolver shall be prepared for a production environment in regards to availability and capacity

SRV-3 The design shall be future expandable with failover sites

SRV-4 The design shall be future expandable with load sharing across multiple nodes

SRV-5 The design shall be future expandable with monitoring and alarm management using SNMP, Graphite, or similar

SRV-6 The design shall be future expandable with backup routines

SRV-7 The design shall be future expandable with runtime upgrade and downgrade procedures

SRV-VIN-2 A VIN shall be identified by an 1-64 byte string (VIN). Improved wording

SRV-PACKAGE-2 A software package shall have an ID string

SRV-PACKAGE-3 A software package shall have a major.minor.patch formatted version number. The ID string plus version is the unique identifier of the package

SRV-PACKAGE-4 A software package shall have a description

SRV-PACKAGE-5 A software package shall have a vendor

SRV-PACKAGE-QUEUE-1 The system shall be able to request a software package to be installed on a subset of all managed VINs

SRV-PACKAGE-QUEUE-6 A list of currently queued updates shall be maintained. One update consist of one or more software packages targeting a specific VIN.

SRV-PACKAGE-QUEUE-7 Each queued update shall maintain a list of completed VINs that have received the update

SRV-PACKAGE-QUEUE-8 Each queued update shall maintain a list of pending VINs that have not yet received the update

SRV-PACKAGE-QUEUE-11 Updates queued for a specific VIN shall be sorted secondarily on the time when the request was made.

SRV-PACKAGE-QUEUE-19 The system shall send a resolve package ID to VIN request to the external resolver system in order to retrieve the VINs and dependencies that should have the package installed. See EXT-RESOLV for details

SRV-PACKAGE-TRANSMIT-1 The Server shall be able to send a wakeup / shoulder tap SMS message to the vehicle, triggering it to connect back to it. Moved from SCHED to FIRST

SRV-PACKAGE-TRANSMIT-2 When the vehicle connects back and identifies itself all updates queued for the VIN shall be transmitted. Moved from SCHED to FIRST

SRV-PACKAGE-TRANSMIT-3 The updates shall be transmitted in the order they are sorted. Allows the server to keep track of which packages are installed where

SRV-PACKAGE-TRANSMIT-4 The update shall be downloadable in chunks. Replaced by SRV-PACKAGE-TRANSMIT-10 - SRV-PACKAGE-TRANSMIT-XXX

SRV-PACKAGE-TRANSMIT-5 The package transfer shall be restartable in case the data link is interrupted

SRV-PACKAGE-TRANSMIT-6 The package transfer restart shall continue at the point the transmission was interrupted

SRV-PACKAGE-TRANSMIT-10 "The Server shall send an ""Software Packages Available"" to a vehicle connected for which updates are queued."

SRV-PACKAGE-TRANSMIT-11 "The ""Software Packages Available"" command shall contain a list of package IDs, descriptive text, and size of the update"

SRV-PACKAGE-TRANSMIT-12 "The Server shall support an incoming ""Initiate Download"" received from the device."

SRV-PACKAGE-TRANSMIT-13 "The ""Initiate Software Download"" command shall contain a list of package IDs to send to the device"

SRV-PACKAGE-TRANSMIT-14 "The Server shall send a ""Start Download"" command to the device to initiate a new download"

SRV-PACKAGE-TRANSMIT-15 "The ""Start Download"" command shall contain a list of package ID contained in the download, a download index, a file size, a chunk size, a target unit, and an install/upgrade/remove command."

SRV-PACKAGE-TRANSMIT-16 "The Server shall send ""Package Chunk"" command containing a fragment (chunk) of a package"

SRV-PACKAGE-TRANSMIT-17 "The ""Package Chunk"" command shall contain a data payload, a chunk index, and an download index refering to the the index provided by the ""Start Download"" command"

SRV-PACKAGE-TRANSMIT-18

SRV-PACKAGE-TRANSMIT-19 "The Server shall support an incoming ""Chunks Received"" command sent by the device"

SRV-PACKAGE-TRANSMIT-20 "The ""Chunk Received"" shall contain a download index, and a list of successfully received and stored chunks for that package."

SRV-PACKAGE-TRANSMIT-21 The Server shall inspect the list of successfully received chunks and select as the next chunk to send the lowest indexed chunk not yet received by the device.

SRV-PACKAGE-TRANSMIT-22 "The Server shall send a ""Finalize Download"" command when a ""Chunks Received"" is received from the device indicating that all chunks have been received and stored."

SRV-PACKAGE-TRANSMIT-27 "If a chunk has been sent 5 times, but has not shown up as successfully received in subsequent ""Chunks Received"" reports, the download shall abort."

SRV-PACKAGE-TRANSMIT-28 "If a chunk has been sent 5 times with no subsequent ""Chunks Received"" command being received at all within a given period of time, the download shall abort."

DEV-1 The device shall receive and process wakeup / shoulder tap SMS. Please see Appendix B, Use Cases DEV, TRANSFER, and INSTALL_* for a detailed description of protocol flow.

DEV-2 The device shall, when a shoulder tap SMS is received, connect back to the SOTA server. Moved from SCHED to FIRST

DEV-3 The device shall identify itself to the SOTA server

DEV-4 The device shall receive chunks for an update

DEV-5 The device shall acknolwedge the reception and local storage of each received chunk

DEV-6 The device shall reassemble the chunks for an update

DEV-7 The device shall validate the integrity of the update. Will be covered by RVI

DEV-8 The device shall authenticate the identity of the sender. Will be covered by RVI

DEV-9 The device shall authorize the sender. Will be covered by RVI

DEV-10 The device shall interface with the local package manager

DEV-19 The device shall use RVI for all server communication.

DEV-20 The device software shall execute on top of the latest version of Genivi Demo Platform

DEV-21 The device software shall execute on top of the latest version of Automotive Grade Linux Distribution

DEV-22 The device shall interact with the local Genivi Software Loading Manager (GSLM) through DBUS using a protocol supplied by Genivi. Package manager renamed to Genivi Software Loading Manager

DEV-23 There shall be a DBUS command to send an install command to the local GSLM. Package manager renamed to Genivi Software Loading Manager

DEV-24 There shall be a DBUS command to send an upgrade command to the local GSLM. Package manager renamed to Genivi Software Loading Manager

DEV-25 There shall be a DBUS command to send a remove command to the local GSLM. Package manager renamed to Genivi Software Loading Manager

DEV-26 There shall ba a DBUS command to retrieve a list of all currently installed software from the local GSLM

DEV-27 All DBUS commands shall return an error/success code and a descriptive text that can be forwarded to SOTA Serevr.

DEV-31 All DBUS commands shall be compliant with call structure of the Genivi Software Loading Manager. Protocol will be specified by Genivi

DEV-32 The device shall use RVI to communicate with the server

DEV-33 The device shall use the JSON Data Link and JSON Protocol supplied by the RVI project for its server communication to ensure JSON-based traffic. All traffic sent between server and client will be JSON formatted, regardless of communication channel (SMS, WiFi, 3G, etc). Other protocols (HTTP, OMA-DM FUMA, etc) can be implemented as RVI plugins.

DEV-34 "The device shall support an incoming ""Software Packages Available"" command received from the server"

DEV-35 "The ""Software Packages Available"" command shall contain a list of package IDs, descriptive text, and size of the download"

DEV-36 "The device shall forward the ""Software Packages Available"" command through DBUS to the GSLM ". The Software Loader Manager will interface the HMI to pop a confirmation dialog

DEV-37 "The device shall support an incoming ""Initiate Download"" received through DBUS from the GSLM.". The user selected one or more packages on the HMI and clicked ok

DEV-38 "The ""Initiate Software Download"" command shall contain a list of package IDs to download and install". "Package IDs are selected from those provided by the ""Software Packages Available"""

DEV-39 "The ""Initiate Software Download"" command received from the GSLM shall be forwarded to the SOTA server to initiate the download.". "Will result in a ""Start Download"" command being sent from the Server"

DEV-40 "The device shall support an incoming ""Start Download"" command to initiate a new download"

DEV-41 "The ""Start Download"" command shall contain a list of package ID contained in the download, a download index, a file size, a chunk size, a target unit, and an install/upgrade/remove command.". "Multple packages may be contained in a single download. Packages can either be dependencies, or bundled packages from the ""Initiate Software Download"" package. Target tells the GSLM if this is a local package, or if it is destined for a module managed by the Module Loader."

DEV-42 "The device shall support an incoming ""Package Chunk"" command containing a fragment (chunk) of a package"

DEV-43 "The ""Package Chunk"" command shall contain a data payload, a chunk index, and an download index refering to the the index provided by the ""Start Download"" command". "Download index allows multiple donwloads to happen in parallell. payload size is specified by chunk size in ""Start Download"""

DEV-44 The device shall store each received chunk on in secondary storage. Downloaded images are reassembled, chunk by chunk on the device side.

DEV-45 "The device shall send a ""Chunks Received"" report back to the SOTA Server"

DEV-46 "The ""Chunk Received"" shall contain a download index, and a list of successfully received and stored chunks for that package.". [1-10,12-15,21,23,25,27-30]

DEV-47 "The ""Chunk Received"" command shall be sent at after ""Package Chunk"" command has been successfully stored.". Overkill, but increases robustness.

DEV-48 "The device shall support an incoming ""Finalize Download command to finish the download". "Will only be sent when ""Chunks received"" reports that all chunks have been received."

DEV-49 "The ""Finalize Download"" command shall contain a download index.". Clears the device to start the installation process.

DEV-50 The device shall verify that all chunks have been received when a download is finalized.

DEV-51 The device shall verify the source and authenticity of the download

DEV-52 If either verification fails, an install failure shall be sent back to the SOTA server for all Package IDs in the download

DEV-53 "The device shall forward the finalized download to the GSLM together with the install/upgrade/remove command and target unit specified in the ""Start Download"" command.". Commands to be sent are specified by DEV-23 - DEV-27

API-1 The Server shall support an API, allowing its functionality to be accessed by external apps and services

API-2 The API shall be based on Restful HTTP with JSON.bodies

API-VIN-1 The API shall have a command to add VINs

API-VIN-2 The API shall have a command to delete VINs

API-VIN-3 The API shall have a call to search for and return VINs using regexp wildcards. Duplicate of API-VIN-7 - 8

API-VIN-7 The API shall have a VIN search command

API-VIN-8 The search command shall support a VIN regexp to match against

API-PACKAGE-1 The API shall have a command to upload packages to the system

API-PACKAGE-2 Each package shall have an ID string specified

API-PACKAGE-3 Each package shall have a version number specified so that ID string plus version number creates a unique queue.

API-PACKAGE-5 The API shall have a command to list search for software packages

API-PACKAGE-6 The search command shall support regexp matching for the ID string and the version number

API-QUEUE-1 The API shall have a command to request that an package is to be installed

API-QUEUE-2 The install command shall provide a filter label to be applied to the request. Not necessary with external resolver

API-QUEUE-3 The install command shall return a unique install ID for the install request

API-QUEUE-17 "The API shall have a command to queue an ""Get All Installed Packages"" command for a given VIN"

WEB-1 The web system shall act as a front end toward the SOTA system

WEB-2 The web system shall use the Web API of the SOTA system

WEB-VIN-1 The web system shall have a UI to add VINs

WEB-VIN-18 A VIN added, deleted, or modified by the web system shall update both the server and the external resolver

WEB-PACKAGE-1 The web system shall have a UI to upload packages to the system.

WEB-PACKAGE-2 The upload screen shall have a software package ID string

WEB-PACKAGE-3 The upload screen shall have a software version

WEB-PACKAGE-4 The upload screen shall have a description

WEB-PACKAGE-5 The upload screen shall have a vendor

WEB-PACKAGE-7 The web system shall have a UI to search for software packages

WEB-PACKAGE-8 The search command shall support regexp matching for the ID string and the version number

WEB-PACKAGE-9 Each software package in the returned search result list shall be clickable

WEB-PACKAGE-10 Clicking on an package from the search result shall bring up a property screen for the package

WEB-PACKAGE-11 The package property screen shall show the package ID string

WEB-PACKAGE-12 The package property screen shall show the version number

WEB-PACKAGE-13 The package property screen shall show the description

WEB-PACKAGE-14 The package property screen shall show the vendor

WEB-PACKAGE-19 A package added, deleted, or modified by the web system shall update both the server and the external resolver

WEB-PACKAGE-20 The package property screen shall have a button to list all filters that will be executed when the package is resolved to VINs. "Will queue a ""Get All Installed Packages"" command to the given VIN, using API-QUEUE-17"

WEB-QUEUE-1 The web system shall have a user interface for creating an update to be pushed to one or more VINs

WEB-QUEUE-2 The create update screen shall specify the software package and version to push

WEB-QUEUE-3 The create update screen shall specify the filter tag to apply. Not applicable with external resolver

WEB-QUEUE-7 The create update screen shall have a button to contact external resolver and list all VINs that would receive the update. Will invoke external resolver to map package ID to VINs

WEB-QUEUE-8 The web system shall have a user interface to list all created updates in the system

WEB-QUEUE-9 Each listed update shall be shown with its software package and filter label

WEB-QUEUE-10 Each listed update shall be clickable

WEB-QUEUE-11 Clicking on the update shall bring up the update property screen

WEB-QUEUE-12 The update property screen shall show the information provided by WEB-QUEUE-[2-6]

WEB-QUEUE-13 The update property screen shall show the total number of VINs targeted by the update

WEB-QUEUE-19 The update property screen shall be able to list all VINs that are still waiting to recveive the update

WEB-QUEUE-20 Each VIN listed in WEB-QUEUE-[17-19] shall be clickable

WEB-RESOLV-FILTER-1 The web system shall have a user interface for adding install filters on the external resolver

WEB-RESOLV-FILTER-2 The add install filter screen shall have a filter label

WEB-RESOLV-FILTER-3 The add install filter screen shall have a text field for a boolean expression

WEB-RESOLV-FILTER-4 The add install filter screen shall have a button to syntax check the boolean expression

WEB-RESOLV-FILTER-5 In case the syntax check fails, an error code and text should be showed

WEB-RESOLV-FILTER-6 The web system shall have a button to list all filters on the external resolver

WEB-RESOLV-FILTER-7 Each filter returned in the list result shall be clicklable

WEB-RESOLV-FILTER-8 Clicking on a filter in the list result shall bring up the filter property screen retrieved from the external resolver

WEB-RESOLV-FILTER-9 The property screen shall be able to edit all filter properties

WEB-RESOLV-FILTER-10 The property screen shall support syntax checking of changed boolean expression

WEB-RESOLV-FILTER-11 "The property screen shall have a ""delete filter"" to remove a filter from the external resolver"

WEB-RESOLV-FILTER-12 "The property screen shall have a ""list associated packages"" to list all packages that will have the filter executed when resolved"

WEB-RESOLV-FILTER-13 The property screen shall be able to add a filter to a package. The filter(s) associated with a package will be run over all VINs when the given package is resolved.

WEB-RESOLV-FILTER-14 The property screen shall be able to delete a filter from a package

EXT-RESOLV-1 The system shall rely on an external system, the Resolver, to translate a software package to VINs that are to have the package installed.

EXT-RESOLV-2 The resolver shall have a server-side WebAPI to handle resolve requests.

EXT-RESOLV-3 A resolve request, sent to the external resolver by the system, shall contain a software package ID string.

EXT-RESOLV-4 A resolve request shall return a list of zero or more VIN numbers that the sofware package should be installed on

EXT-RESOLV-API-1 The Resolver shall support an API, allowing its functionality to be accessed by external apps and services

EXT-RESOLV-API-2 The API shall be based on Restful HTTP with JSON.bodies

EXT-RESOLV-FILTER-1 A resolve request shall retrieve the VINs to install an package on by executing one or more filters

EXT-RESOLV-FILTER-2 A single filter shall be associated with zero or more software package IDs

EXT-RESOLV-FILTER-3 The software package ID string of a resolve request shall be used retrieve the all filters associated with the package ID.

EXT-RESOLV-FILTER-4 Each filter retrieved for an package ID in a resolve request shall be run on all VINs in order to filter out those VINs that should receive the update. All filters are AND-ed together.

EXT-RESOLV-FILTER-5 Only VINs that pass all filters associated with the software package ID shall be returned by the resolve request

EXT-RESOLV-FILTER-6 The filter shall specify a boolean expression that has to be true for a specific VIN in order for the software package to be queued to that VIN.

EXT-RESOLV-FILTER-12 The VIN operand shall support regexp matching

EXT-RESOLV-FILTER-13 The finished boolean expression shall be labeled and stored as a named, reusable filter

EXT-RESOLV-FILTER-API-1 The API shall have a command to add new filters

EXT-RESOLV-FILTER-API-2 The added filter shall have a boolean expression

EXT-RESOLV-FILTER-API-3 The added filter shall have a unique label

EXT-RESOLV-FILTER-API-4 The API shall havea a command to check the syntax of a boolean expression

EXT-RESOLV-FILTER-API-5 The syntax check shall return ok or an error code and text

EXT-RESOLV-FILTER-API-7 The API shall have a command to associate a package ID string to a filter. Used during resolve package → VINs to figure out which filter to apply to th egiven VINs

EXT-RESOLV-FILTER-API-8 The API shall have a command to dis-associate a package ID string from a filter

EXT-RESOLV-FILTER-API-9 The API shall have a command to list all filters associated with a package ID string

EXT-RESOLV-FILTER-API-10 The filters associated with the given package ID shall have their filter labels returned

EXT-RESOLV-FILTER-API-11 The API shall have a command to list all packages associated with a filter label.

EXT-RESOLV-FILTER-API-12 The packages associated with the given filter label shall have their package ID strings returned.

EXT-RESOLV-VIN-2 A VIN shall use a VIN number as its primary identifier

EXT-RESOLV-VIN-API-1 The API shall have a command to add VINs

EXT-RESOLV-VIN-API-2 The API shall have a command to delete VINs

EXT-RESOLV-PACKAGE-2 A software package shall have an ID string

EXT-RESOLV-PACKAGE-3 A software package shall have a major.minor.patch formatted version number. The ID string plus version is the unique identifier of the package

EXT-RESOLV-PACKAGE-4 A software package shall have a description

EXT-RESOLV-PACKAGE-5 A software package shall have a vendor

EXT-RESOLV-PACKAGE-API-1 The API shall have a command to specify a package to the external resolver

EXT-RESOLV-PACKAGE-API-2 Each package shall have an ID string specified

EXT-RESOLV-PACKAGE-API-3 Each software package shall have a major.minor.patch formatted version number. The ID string plus version is the unique identifier of the package

EXT-RESOLV-PACKAGE-API-4 Each package shall have a version number specified so that ID string plus version number creates a unique queue.

SRV-VIN-3 A VIN shall be able to ber associated to up to 1000 components. Each component is a potential target for software images

SRV-PACKAGE-6 The software ID string shall support regexp matching when searching

SRV-PACKAGE-7 The software version number shall support regexp matching when searching

API-VIN-4 The API shall have a call to associate a component to an existing VIN. Moved to Resolver

API-VIN-9 The VINs returned by the search shall each have their associated components listed. Moved to Resolver

WEB-VIN-7 The VIN property screen shall list all components installed on the VIN, as retrieved from the external resolver

WEB-VIN-10 The VIN property screen shall have a button for adding a component on the external Resolver. Duplicate of WEB-RESOLV-COMP-1

WEB-VIN-11 Adding a component shall specify the component part number. Duplicate of WEB-RESOLV-COMP-1

WEB-QUEUE-21 Clicking on a VIN shall list all software packages and version included in the update for the given VIN

WEB-RESOLV-COMP-1 The web system shall have a UI to add components to the external resolver using a component part number

WEB-RESOLV-COMP-2 The web system shall have a UI to delete components from the external resolver

WEB-RESOLV-COMP-3 The web system shall have a UI to search for components in the external resolver

WEB-RESOLV-COMP-4 The web system’s components shall be searchable by part number regular expressions

WEB-RESOLV-COMP-5 The componens returned by a search shall be clickable

WEB-RESOLV-COMP-6 Clicking on a component from the search result shall bring up a property screen for the component

WEB-RESOLV-COMP-7 The component property screen shall show the part number

WEB-RESOLV-COMP-8 The component property screen shall show the description

WEB-RESOLV-COMP-9 The component property screen shall have a button to list all VINs that the component is installed on

WEB-RESOLV-COMP-10 The web system shall have a UI to add a component to a specific VIN using the external resolver.

EXT-RESOLV-FILTER-7 The boolean expression shall have operands that identify specific components by their part number

EXT-RESOLV-FILTER-8 The component part number in the expression shall support regexp matching

EXT-RESOLV-FILTER-API-6 The API shall have a command to delete filters identified by their label

EXT-RESOLV-VIN-3 A VIN shall be able to ber associated to up to 1000 components

EXT-RESOLV-VIN-API-3 The API shall have a call to specify a component has been installed in an VIN

EXT-RESOLV-COMP-1 The resolver system shall manage up to 1 million components. Used by filtering process to require that specific components are installed in order for a package to be installed

EXT-RESOLV-COMP-2 A component has a part number. Main identifier used by software packages.

EXT-RESOLV-COMP-3 A component has a description

EXT-RESOLV-COMP-4 A component can have one or more VINs associated with it. Each VIN has zero or more components installed on it.

EXT-RESOLV-COMP-API-1 The API shall have a command to add a component to the system with a part number

EXT-RESOLV-COMP-API-2 The API shall have a command to specify that a component is installed on a specific VIN. "Will make has_component(""xxx"") return true in a filter run over the given VIN."

EXT-RESOLV-COMP-API-3 The API shall have a command to search for and return components using regexp wildcards

EXT-RESOLV-COMP-API-4 The returned components shall be listed with their part number

EXT-RESOLV-COMP-API-5 The returned components shall be listed with their descriptions

EXT-RESOLV-COMP-API-6 The API shall have a command to list all VINs that a component is installed on

SRV-VIN-4 Each component associated with a VIN shall have a reference to its currently installed software image.

SRV-VIN-5 The component reference to the software image shall be the ID string and version number

SRV-PACKAGE-8 Each software package shall be maintain a list of all VINs it is installed on

SRV-PACKAGE-QUEUE-20 The system shall use EXT-RESOLV-PACKAGE-API to update the resolver with packages installed and removed from each VIN targeted by an update, as reported back by the device. Allows resolver to keep track of which packages are installed on which VIN.

SRV-PACKAGE-QUEUE-21 "The system shall be able to queue a ""Get All Installed Packages"" command to a device in order to retrieve its currently installed packages". Used to synchronize Resolver’s list of installed packages on a VIN with reality

SRV-PACKAGE-QUEUE-22 "When a ""Get All Installed Packages"" result is received from a device, the EXT-RESOLV-PACKAGE-API shall be used to reset the resolver’s list of installed packages for the given VIN."

SRV-PACKAGE-TRANSMIT-7 Once installed on a VIN, an installation acknolwedgement shall be sent back to the SOTA server

SRV-PACKAGE-TRANSMIT-8 The installation acknowledgement shall be used to update the association between a VINs components and their installed software packages and versions

SRV-PACKAGE-TRANSMIT-9 In case of an installation failure, there shall be an error code and error text returned to the SOTA server. Executes SRC-PACKAGE-QUEUE-22

SRV-PACKAGE-TRANSMIT-23 "The ""Finalize Download"" command shall contain a download index."

SRV-PACKAGE-TRANSMIT-24 "The Server shall support an incoming ""Installation report"" command sent by the device"

SRV-PACKAGE-TRANSMIT-25 "The ""Installation Report"" shall contain a package ID, a status code indicating success or failure, the currently running version of the package, and a descriptive text of the outcome.". Forwarded by SOTA Server to external resolver so that it can keep track of which packages are installed on which VINs

SRV-PACKAGE-TRANSMIT-26 The Server shall forward the Installation report to the external resolver. As specified by SRV-PACKAGE-QUEUE-20

SRV-PACKAGE-TRANSMIT-29 An aborted download shall be reported to thee external resolver

SRV-PACKAGE-TRANSMIT-30 "An aborted download shall trigger a ""Abort Download"" command being sent to the device"

SRV-PACKAGE-TRANSMIT-31 "An ""Abort Download"" command shall contain the download index of the failed download". Either the device receives it and cancels the download, or the device will time out the download and cancel it.

DEV-1 FIRST The device shall receive and process wakeup / shoulder tap SMS. Please see Appendix B, Use Cases DEV, TRANSFER, and INSTALL_* for a detailed description of protocol flow.

DEV-11 The device shall report installation success back to the SOTA server. Forwarded by SOTA Server to external resolver so that it can maintain a list of currently installed packages.

DEV-12 The device shall report installation failure back to the SOTA server. Installa

DEV-13 In case of installation failure, the device shall report an error code and an error text back to the server

DEV-14 "The device shall support a ""Get currently installed packages command"" (GetCurrentPackages)". Needed sync up a mismatch between a device’s view of installed packages and that of the backend server.

DEV-15 When a GetCurrentPackages command is received, the device shall report back a list of currently installed packages

DEV-16 Each package in a report shall be identified by its package ID string and version number

DEV-17 There shall be a resend attempt in case reporting of package installation results or currently installed packages fails

DEV-18 The device shall, when it connects to the SOTA server, validate the authenticity of the SOTA server. Both client and server side validation are needed.

DEV-28 The device shall be able to report locally changed software packages to the SOTA Server

DEV-29 The device shall receive information about locally changed packages through a DBUS command

DEV-30 The report shall contain the package ID, timestamp, and operation (install, upgrade, remove) carried out locally.

DEV-54 "The device shall support an incoming DBUS ""Installation Report' command from the local GSLM."

DEV-55 "The ""Installation Report"" shall contain a package ID, a status code indicating success or failure, the currently running version of the package, and a descriptive text of the outcome.". The running version can either be the new version, the existing version, or a reverted factory version.

DEV-56 The device shall forward the installation report to the SOTA Server. SOTA Server will forward it to the external resolver, allowing it to maintain its database of installed packages.

DEV-57 "If no additional ""Package Chunks"" are received for an ongoing download within a given timeout period, the download shall abort"

DEV-58 "If a ""Start Download"" command is received with a download index equal to that of an ongoing download, the ongoing download shall be aborted to make way for the new download.". Allows timed out downloads to be restarted.

DEV-59 "The device shall support an incoming ""Abort Download"" command "

DEV-60 "The ""Abort Download"" command shall contain the download index"

DEV-61 An aborted download shall delete any stored data on the device.

DEV-62 "If the download index of an ""Abort Download"" command cannot be found, the command shall silently be ignored.". """Start Download"" command was lost and never received by client"

API-VIN-5 The API shall have a call to associate an software image to a VIN. Moved to Resolver

API-VIN-6 The software image associated with a VIN shall be associated with a specific component installed on that VIN. Removed association between package and specific component. Packages are now generically installed on a VIN without component association.

API-VIN-10 The VINs returned by the search shall each have their associated installed software packages listed

API-VIN-11 The API shall have a command to list all historic package updates sent to a VIN since the VIN was created

API-VIN-12 Each update returned by a historic list command shall contain a result code reflecting success or failure of installing the package

API-VIN-13 Each update returned by a historic list command shall contain all dependent-upon packages transmitted with the original package in order to satisfy all dependencies of the installed package

API-VIN-14 Each update returned by a historic list command shall contain a time stamp of when the update completed or failed

API-PACKAGE-7 The API shall have a command to list all the VINs that a specific version of a software package is installed on. Database of which packages are installed on which VIN now handled by resolver

API-PACKAGE-8 The API shall have a command to list all the VINs that a specific version of a software package is queued for installation on. Duplicate of API-QUEUE-7

WEB-VIN-8 Each component on a VIN property screen shall be listed with its currently installed software image and version. Packages no longer associated with target components on a VIN.

WEB-VIN-9 The VIN property screen shall list all installed software packages (including dependencies), as retrieved from the external resolver

WEB-VIN-12 The VIN property screen shall have a button for adding a (manually installed) software package on a VIN. API Call sent to the Resolver

WEB-VIN-13 The software package added to the system shall be specified with a ID string

WEB-VIN-14 The software package added to the system shall be specified with a version number

WEB-VIN-15 The software package added to the system shall be specified with a description

WEB-VIN-16 The software package shall be assocaited with a component installed on the VIN. Packages no longer associated with target components on a VIN.

WEB-VIN-17 The VIN property screen shall have a button to list all software packages currently queued to it

WEB-VIN-19 The VIN property screen shall have a button to re-synchronize the list of installed packages with those actually installed on device

WEB-PACKAGE-16 The package property screen shall have a button to list all VINs that the package is installed on. Interfaces resolver to retrieve lsit

WEB-PACKAGE-17 Clicking on the installed VIN button shall bring up a list of all VINs with the package installed

WEB-PACKAGE-18 The package property screen shall have a button to list all VINs that the package is queued for

WEB-QUEUE-14 The update property screen shall show the total number of VINs that have had the update successfully installed

WEB-QUEUE-15 The update property screen shall show the total number of VINs that have failed to have the update installed

WEB-QUEUE-16 The update property screen shall show the total number of VINs that are still waiting to receive the update

WEB-QUEUE-17 The update property screen shall be able to list all VINs that have had the update succsessfully installed

WEB-QUEUE-18 The update property screen shall be able to list all VINs that failed to have the update installed

EXT-RESOLV-FILTER-9 The boolean expression shall have operands that identify the currently installed packages packages.

EXT-RESOLV-FILTER-10 The currently installed package is identified by its ID string and version number

EXT-RESOLV-FILTER-11 The ID string and version number of the currently installed package shall support regexp matching

EXT-RESOLV-VIN-4 A VIN shall be able to handle up to 5000 installed software packages

EXT-RESOLV-PACKAGE-6 Each software package shall be maintain a list of all VINs it is installed on. Used by filter has_package() operand

EXT-RESOLV-PACKAGE-API-5 The resolver shall have a command to specify that a given package has been installed on a VIN. Called by the SOTA Server when a device reports that an update has been installed.

EXT-RESOLV-PACKAGE-API-6 The resolver shall have a command to specify that a given package has been deleted from a VIN. Called by the SOTA Server when a device reports that an update has been updated/removed

EXT-RESOLV-PACKAGE-API-7 The resolver shall have a command to search for all packages installed on a VIN

EXT-RESOLV-PACKAGE-API-8 The resolver shall have a command to search for all VINs that a package is installed on.

SRV-PACKAGE-QUEUE-9 Each VIN targeted by a queued update shall maintain a list of packages that are rolled into the update for that specvific vin. All packages to be added to original package in order to satisfy dependencies are provided by EXT-RESOLV

SRV-PACKAGE-DEPS-1 Each VIN, as returned by the external resolver, shall be have a dependency check done for the package that is to be installed

SRV-PACKAGE-DEPS-2 The depency check shall compare the list of packages already installed on the VIN with the dependency graph of the new package to be installed. Which packages does the package about to be installed need on this specific VIN in order to function.

SRV-PACKAGE-DEPS-3 If an dependent package, required by the package to be installed, is currently not installed on the VIN, the required package will be added to the update for that specific VIN.

SRV-PACKAGE-DEPS-4 If installing one or more of the packages in an update on a VIN would break dependencies for packages already installed on that VIN, the update shall fail for the given VIN and be reported back to the server

SRV-PACKAGE-DEPS-5 A software package shall be dependent on up to 100 other software packages

SRV-PACKAGE-DEPS-6 Software package depencies shall form a graph of sub dependencies. A requires B, which requires C and D.

SRV-PACKAGE-DEPS-7 A dependency shall be identified by a software package ID string and a version number

API-PACKAGE-4 Each package shall have an optional list of dependencies specified. Moved to resolver

API-PACKAGE-9 The API shall have a command to list the dependencies for a specific package. Moved to resolver

WEB-PACKAGE-6 The upload screen shall allow to specify dependencies on one or more exisiting software packages. Interfaces resolver to handle dependencies

WEB-PACKAGE-15 The package property screen shall show all the software package dependencies the shown package has. Interfaces resolver to handle dependencies

EXT-RESOLV-DEPS-1 Each VIN returned by a resolver for a specific package shall have a dependency check done for that package

EXT-RESOLV-DEPS-2 The depency check shall compare the list of packages already installed on the VIN with the dependency graph of the new package to be installed

EXT-RESOLV-DEPS-3 If an dependent package, required by the package to be installed, is currently not installed on the VIN, the required package will be provided with the given VIN when returned to the SOTA Server.

EXT-RESOLV-DEPS-4 If installing one or more of the packages in an update on a VIN would break dependencies for packages already installed on that VIN, an error will be logged for the given update by the resolver and the VIN is removed from the set of VINs returned by the resolver

EXT-RESOLV-DEPS-5 A software package shall be dependent on up to 100 other software packages

EXT-RESOLV-DEPS-6 Software package depencies shall form a graph of sub dependencies.

EXT-RESOLV-DEPS-7 A dependency shall be identified by a software package ID string and a version number

EXT-RESOLV-DEPS-API-1 The resolver shall have a command to add a dependency from one package toward another

EXT-RESOLV-DEPS-API-2 The resolver shall have a command to delete a dependency from one package toward another

EXT-RESOLV-DEPS-API-3 The resolver shall have a command to list all dependencies of a package. Can be called recursively to get entire dependency graph

SRV-PACKAGE-QUEUE-2 The request shall have an earliest start date. Do not install before 2016-01-01.

SRV-PACKAGE-QUEUE-3 The request shall have a latest install completion date. Do not install after 2016-04-01

SRV-PACKAGE-QUEUE-4 If a software package cannot be installed on one ore more targeted VINs within the specified period, they failed VINs shall be logged

SRV-PACKAGE-QUEUE-5 The request shall have a priority from 1 to 100. Used when updates are queued to individual vehicles. See below

SRV-PACKAGE-QUEUE-10 Updates queued for a specific VIN shall be sorted primarily on ascending request priority. Allows high-priority updates to skip the queue and be pushed out earlier to the vehicle

API-QUEUE-4 The API shall have a command to cancel a previously queued install request

API-QUEUE-5 Canceling an install request will delete any pending updates that have yet to be transmitted to their targeted VINs.

API-QUEUE-6 Canceling an install request shall not affect any packages already installed on their targeted VINs.

API-QUEUE-7 The API shall have a command to list all VINs targeted by a specific install request, identified by the install ID

API-QUEUE-8 The list command shall return all VINs which the install request was successfully completed on

API-QUEUE-9 The success report for a VIN shall include a date and time stamp.

API-QUEUE-10 The list command shall return all VINs for which the install request is still pending on the server

API-QUEUE-11 The list command shall return all VINs for which the install request failed

API-QUEUE-12 The failure report for a VIN shall include a date and time stramp.

API-QUEUE-13 The failure report for a VIN shall include a reason code such as time out, dependency failure, etc.

API-QUEUE-14 The failure report for a VIN shall include a reason text.

API-QUEUE-15 The list command shall, for each returned VIN, list the software packages included in the update, including dependencies

API-QUEUE-16 The list command shall return all VINs for which the install request has started transmission, but has not yet completed

WEB-VIN-2 The web system shall have a UI to delete VINs

WEB-VIN-3 The web system shall have a UI to search for VINs

WEB-VIN-4 The web system’s VINs shall be searchable by regular expressions

WEB-VIN-5 Each VIN by a search shall be clickable

WEB-VIN-6 Clicking on a VIN from the search result shall bring up a property screen for the VIN

WEB-QUEUE-4 The create update screen shall specify the earliest start date for the update to be installed

WEB-QUEUE-5 The create update screen shall specify the latest end date for the update to be installed

WEB-QUEUE-6 The create update screen shall specify a priority

WEB-QUEUE-22 "The update property screen shall have a ""cancel update"" button."

WEB-QUEUE-23 "Clicking on the ""cancel update"" button shall cancel any updates to VINs that are not yet complete"

WEB-QUEUE-24 "Clicking on the ""cancel update"" button shall delete the update itself."