TIOVX User Guide
TIOVX Safety Considerations

TIOVX Usage Recommendations for Safety

When utilizing TIOVX within a safety system, there are a few things to note regarding the implementation of various API's.

Delay Object Support

The vx_delay objects have limited support within TIOVX, particularly when using them within pipelining. Thus, it is not recommended to use vx_delay objects with pipelining. The section Pipelining with Delay Objects provides more details on this limitation and alternative means by which to implement similar functionality.

Composite Object Pipelining Support

Similarly, composite objects such as vx_object_array and vx_pyramid have certain limitations with pipelining. The section Pipelining with Composite Objects provides more details on this limitation and alternative means by which to implement similar functionality.

Safety Implications of TIOVX Map and Copy API Implementation

Per the section Map and Copy API Usage in TIOVX, there are some safety implications for the map and copy API's implementations within TIOVX. Given that these API's allocate memory prior to graph verification, the application developer must by cognizant of this fact when creating the TIOVX-based application. In particular, if using data objects as exemplars or other such elements disconnected from the graph, it is possible that the available memory of the system can be reached prior to the call to vxVerifyGraph and thus should be taken into account when designing the system.

Further information

For full details, please reference the TIOVX usage sections at the location TIOVX Usage

TIOVX Memory Management for Safety

A critical component of safety SW systems is the memory management scheme. Please reference the section TIOVX Memory Optimizations for details on how memory management is handled in TIOVX and how it facilitates safety.

TIOVX Resource Teardown

For applications created using TIOVX as the middleware, the resource teardown shall be considered in the development of the applications. While TIOVX provides API's to release references that have previously been created, this logic must be called in the case that an event is received at the application level which causes an abort. Signal handler logic should handle the teardown of OpenVX data objects that had previously been created. The implementation of this logic will depend on the OS used by the OpenVX host core. Future versions of TIOVX and the PSDK RTOS will contain examples which illustrate how this can be done.

TIOVX Import Reference

The tivxReferenceImportHandle API has several important restrictions in how it is to be used within TIOVX. The API guide gives details as to the requirements of the imported handle, which must be adhered to. In particular, there are a few important aspects of the imported handles that need to be reviewed below:

  • Memory region requirements. An error is thrown if the memory is not created from the region specified
  • Memory alignment requirements. While there is not a check for this given that it is simply a memory address, the API is required to be used for memory allocation will automatically align the memory to the required alignment
  • There is an error thrown if the corresponding number of entries doesn't match a set of number of valid addressesIf the total number of memory pointers are less than required for the reference (i.e., there are 2 pointers for a 3 plane image), then an error will be thrown.
  • If more pointers are supplied than are needed (i.e., 4 pointers for a 3 plane image), then only a warning will be thrown and the additional pointers are ignored.

For more information about how to use this API, please refer to the Producer/Consumer application within vision_apps as well as the test cases found at tiovx/conformance_tests/test_tiovx/test_tivxMem.c