TIOVX User Guide
TIOVX Safety Scope

What is and is not in scope for TIOVX safety

What is in scope for TIOVX safety:

  • TI's implementation of the OpenVX framework (source/framework) with few exceptions listed in the "out of scope" section below.
  • The OS platform layer (source/platform)
  • The dependent utils of TIOVX within app_utils. The specific libraries within this component are listed below:
    • utils/ipc
    • utils/mem
    • utils/misc
    • utils/rtos
    • utils/timer

Within the modules which we are in scope for safety, TI will be generating code coverage reports for the safety release during the 10.1 release. As a part of this effort, TI is utilizing macros to remove code from the final report which has approved deviations. Note that these macros are still enabled by default in our build using concerto. Therefore, if different build systems are being used, the below macros should still be defined in these environments:

  • LDRA_UNTESTABLE_CODE
  • HOST_ONLY

Please note the following which are out of scope for safety of TIOVX:

  • OpenVX standard kernels
  • Supernode extension (Note: this is not yet enabled on J7 platforms, but there are still references to it in the framework. These are wrapped under the BUILD_BAM macro.)
    • tiovx/source/framework/vx_graph_supernode.c
    • tiovx/source/framework/vx_super_node.c
  • VXU functions
    • tiovx/source/vxu
  • Debug logging functionality
    • tiovx/source/framework/vx_log_resource.c
  • RT logging functionality
    • tiovx/source/framework/vx_log_rt_trace.c
    • tiovx/source/framework/vx_log_rt_trace_host.c
  • Export to dot file functionality
    • tiovx/source/framework/vx_graph_export_dot.c

Important note to how application shall be written using TIOVX that are used for safety: the "vx-" or "tivx-" functions shall only be used within a safety application, not the "own-" prefixed functions. These functions shall only be called within the context of the framework itself, not applications.

TIOVX OS Support

The aspects of TIOVX which are considered under the safety qualification effort are the framework, platform layer and associated utils layers. For the remote cores supported via TIOVX safety, the safety OS which is supported is SafeRTOS. For the host side components, given that the Linux and QNX OS layers do not support safety, a safety OS would need to be used in place of Linux and QNX. Please note though that the generic POSIX platform layer will have safety qualification collateral (e.g., MISRA-C, Code Coverage, Requirement documentation, etc).