Open Test System  
Support, Maintenance and FAQ

Table of Contents

After the software has been released and delivered, questions may arise or errors or defects may become apparent. The software is maintained and further developed for this purpose and the support can answer the upcoming questions.

Maintenance includes the following services:

  1. Product improvements and optimizations
  2. Updates to new versions and extensions of the OTX standard
  3. Updates to new versions of the supported operating systems
  4. If required and in consultation with the user, updates to new versions of dependent software, e.g. Java or .NET
  5. Troubleshooting (outside the warranty) and elimination of defects
  6. Provision of new software versions

Product support includes the following services:

  1. Answers to questions that cannot be answered from user training and user documentation
  2. Support with questions about using the software
  3. Support with integration of the OTX-Runtime API into a target environment, excluding embedded systems

Further topics:

  1. Support and Maintenance Contract
  2. Support Requirements
  3. Support Proceeding
  4. Extended Integration Support
  5. Support Issue Tracking System (Redmine)
  6. Frequently Ask Questions

Support and Maintenance Contract

In order for the user to receive product support and maintenance, he must have a valid support and maintenance contract. Support helps with open questions and maintenance provides new, improved versions of the software. Each license includes 30 days or one year of support and maintenance (outside Europe one year is mandatory). Product support and maintenance can be extended by one year every year. However, an extension can only be made directly after an existing support and maintenance period.

Note: An extension of product support & maintenance only apply directly after an existing period. The extension therefore begins on the first day after the end of the previous period, regardless of the day of the order.

Support Requirements

Product support includes support for using the OTX tools. It is offered with the product and together with annual maintenance. Since the OTX tools require special knowledge in the area of ​​vehicle diagnostics, we assume the following requirements for product support.

Requirements:

  1. Knowledge required for the role of an OTX Programmer (someone who writes OTX code):
    1. Basic programming knowledge
    2. Attendance of a qualified OTX user training course, see OTX according to ISO 13209 – User Training
    3. Understanding of the OTX user documentation for the OTX development environment and the OTX standard
  2. Knowledge required for the role of Target System Programmer (someone who integrates the OTX-Runtime API into a target system):
    1. Software developer
    2. Attendance of a qualified OTX user training course, see OTX according to ISO 13209 – User Training
    3. Understanding of the OTX user documentation for the interface to be integrated

Note: The intention of product support is to provide quick and efficient support and to answer open questions. The step-by-step development of the knowledge required above does not correspond to this intention, but usually leads to problems and misunderstandings on both sides.

Note: All questions that do not directly concern the delivered software are not part of the product support, but can be covered by Extended Integration Support.

Important: The integration of the software into a specific target system usually leads to profound questions that affect not the software itself but the entire system. Due to the product complexity, Extended Integration Support is strongly recommended!

Important: For the integration of the software into an embedded system a valid Extended Integration Support in mandatory!

Important: For support in programming of own custom implementations, Extended Integration Support is mandatory! We know our software best, which is why we recommend having us develop your own custom implementations.

Support Proceeding

If a question or problem arises, a ticket must be created, see Support Issue Tracking System (Redmine).

Note: To access the EMOTIVE Issue Tracking System, an account must be set up. Please contact EMOTIVE!

Important: If the error is related to the integration of the OTX-Runtime API in an own application, the error must be reproduced using the supplied reference application, before creating a ticket.

  1. Depending on the type of problem, e.g. error or support request, the corresponding Ticket Type is selected.
    1. A feature request can also be made using the Feature ticket type.
    2. One ticket should be created for each problem. Do not combine several independent problems in one ticket. If there are any ambiguities, the ticket can be split later.
  2. The ticket should contain the following information:
    1. Brief description of the problem
    2. Detailed, comprehensible description to be able to reproduce the problem (use OTX terminology!)
    3. Specify the name and version number of the software used
    4. If possible, attach log or trace files that contain the problem to the ticket, see Logging and Tracing
    5. Write example code, for example in OTL or DotNet, in the ticket

      Note: Foreign program code, foreign terms, file formats or log files cannot be processed without Extended Integration Support.

  3. The ticket should be assigned to the technical contact

Extended Integration Support

For all questions that go beyond the Support and Maintenance Contract, extended integration support can be ordered on an hourly account basis. These include the following activities:

  1. Advice on the basics and application of diagnostic standards, especially OTX
  2. Advice on the integration, configuration and application of the OTX-Runtime API
  3. Introducing improvements, optimizations and extensions to the diagnostic standards to the standardization committees at ASAM and ISO
  4. Developing and specifying recommendations for optimizing the OTX runtime for a specific target system
  5. Developing and specifying recommendations for optimizing the overall system, especially the MVCI diagnostic runtime system and the D-PDU API
  6. Review and technical assessment of requirements for the OTX runtime
  7. Implementation, testing and provision of user-specific changes to the OTX runtime
  8. Support in troubleshooting including analysis of logging results
  9. Correction of errors that only occur in the specific vehicle environment
  10. Implementation of measures to ensure code quality, such as code review after commit, static code analysis, sanitizer, API unit tests via Google Test as well as OTX unit tests and OTX use case tests for the runtime
  11. Expansion of the OTX unit tests or other suitable tests to check these errors for regression
  12. Development and implementation of integration tests for the target system
  13. Conducting code reviews
  14. Change management
  15. Maintenance of one or more code branches for use in the vehicle
  16. Support in the creation of OTX sequences
  17. Participation in meetings

Note: The elimination of errors and the correction of defects in the standardized parts of the OTX-Runtime API are not part of the Extended Integration Support, as they are already covered by Support and Maintenance Contract. This does not apply to optimizations and non-standardized extensions that result from the integration into a specific target system.

Support Issue Tracking System (Redmine)

The EMOTIVE Issue Tracking System is server-based software for the collaborative processing of tickets, see EMOTIVE Issue Tracking System. The system ensures that no task is lost and that a complete overview of the processes to be processed is possible at all times.

Note: EMOTIVE uses the open source software **Redmine* as an issue tracking system.

Note: To access the EMOTIVE Issue Tracking System, an account must be set up. Please contact EMOTIVE!

Tickets

The tickets are the central element. Tickets are assigned to projects. Tickets can be organized hierarchically and links can be created between tickets. Tickets include:

Ticket Types

Depending on the content and purpose of the ticket, the ticket must be assigned one of the following types.

Ticket Type Description
Main Main feature, usually has sub-tickets
Feature New feature or enhancement
Gap/Lack Defect or gap that does not prevent usage
Bug Usage preventing error
General General ticket outside of the implementation (e.g. effort estimation, specification creation etc.)
Support Support request (no code changes)

Note: The type of a ticket can change during processing. For example, if it is determined that it is not a bug but an incorrect application, the type can be changed from "Bug" to "Support".

Ticket Priorities

All tickets are assigned to the employees. The employees process the tickets in the order of their priority and the date of creation. If a higher priority ticket is assigned during processing, the rules in the table below apply.

Ticket Priority Description
LOW Subordinate, can be done at some point (background task)
NORMAL Edit in order of creation
HIGH A NORMAL ticket can be completed. A LOW ticket should be paused (Pending) but can be processed until the EOB.
URGENT A HIGH ticket can be processed until the EOB. A NORMAL and LOW ticket must be paused (Pending) as quickly and reasonably as possible.
IMMEDIATE All other tickets must be paused (Pending) as quickly and reasonably as possible.

Ticket States

A ticket always has exactly one of the following states, whereby the status process is described in the flowchart.

Ticket States Description
New The ticket is generated by the creator. It contains a simple, clear and sufficient specification of the task for the editor. If the ticket is RELEASE relevant a link to a certain Release Plan version must be added.
In Progress The editor works on the ticket. The estimated progress and due date must be updated at the end of the working day!
Feedback The editor has a question or a tip for the creator.
Pending The editor has to pause the work due to another ticket or if some requirements missing. The reason for pending should be written in the ticket and the other ticket must be linked as a reference.
Resolved The editor has completed and tested the work. A short summary as well as the revision number should be written in the ticket.
In Testing The tester tests the implementation against the specification.
Tested The tester successfully tested the implementation. He thus releases the implementation for delivery.
Closed This optional status does not have to be used. It is only used to clean up the ticket system.
Rejected The ticket is invalid.
Ticket Status Process

Ticket Relations

Tickets that are related to other tickets must be linked. The following relationships are possible:

Relation Description
Relationship The ticket has a technical relationship with another ticket.
Duplicate The ticket is a duplicate of another ticket.
Blocked The processing of the ticket is blocked by another ticket, see also Status Pending.
Predecessor Before the ticket can be processed, another ticket must first be completed.