OpenVX SC 1.1公開
先日、KhronosがOpenVX1.2を公開した。
クロノス・グループ、クロス・プラットフォームにおける高電力効率コンピュータ・ビジョン処理の高速化向けを可能とする「OpenVX 1.2」を発表
その際、OpenVX1.1のSC版(Safety Critical版)も併せて公開している。
本投稿ではOpenVX 1.1 SC版とOpenVX 1.1 無印版との差分概要をまとめる。
（もちろん詳細および正確な情報が必要な場合は本家仕様をご参照ください）
ちなみに「SC版とは何か」についてはKhronosのプレスリリースで次のように述べている。
先進運転支援システム（ADAS）や自動運転車、医療やプロセス制御用アプリケーションをはじめ、新たに創出されるセーフティ・クリティカル市場の多くにおいて、ビジョン処理は必須要素になると予想されます。クロノスは、セーフティ・クリティカルなシステムを対象とし、上記の高信頼性市場における厳しい要件に対応できる高効率システムの認定を支援するため、OpenVX 1.1仕様の改訂版となるOpenVX SC 1.1を発表しました。
変更点（※章節番号はPDF版のもの）
import, exportを標準サポート
OpenVXでは画像に対する処理をノード、それらを組み合わせたものをグラフと呼び、グラフを生成しまとめて実行することをひとつの大きな特徴としている。
このグラフ生成が、OpenVX 1.1 無印版ではプログラム実行時に生成するしかなかったが、SC版では事前に生成したバイナリを実行できるように拡張されている。
この変更の目的は、後述する「development featureとdeployment featureの分離」の実現。
なお、この機能はOpenVX 1.1 Export And Import Extensionとして仕様化されていて、無印版にも適用可能になっている。
例えば、同じくextensionとして仕様化されているOpenVX 1.2 Neural Network Extensionを使うときに利用する。
development featureとdeployment featureの分離
SC版ではAPIをdevelopement featureとdeployment featureに分類している。
アプリケーション開発者は、development featureを使って開発し、最終商品ではdeployment featureだけを使って実装する。
1.1 SC版の場合、development featureは全APIを指す。
一方deployment featureには、グラフを作成するための機能（vxXXXNode()とかvxCreateGraph()など）は含まれない。
つまり、開発中はdevelopment featureを使って動的にgraphを作り試行錯誤する。
そしてgraphが固まったらexportして、最終商品ではimportしたグラフのみを実行する、といったプロセスが想定されている。
この変更の目的は、最終商品で使う機能を限定することで、機能安全対応時に考慮すべき範囲を減らすこと。
development featureは、正しく機能すれば良いのに対し、deployment featureは正しく機能することはもちろん、リアルタイム性、エラー時のリカバリ、再現可能性などを求められる。
Immediate Mode Functions (vxuXXX())の削除
OpenVX 1.1 無印版では、最大のウリであるgraphを作成して実行するAPI体系とは別に、OpenCV-likeな各nodeの処理を関数コールとして実行するImmediate Mode Functionsと呼ばれるAPI体系 (vxuXXX())が用意されている。
一方SC版ではImmediate Mode Functionsがすべて削除されている。
この変更の目的は、Immediate Mode Functionsがもともとお手軽にOpenVXを試してみるための機能なので、削除することで機能安全対応で考慮すべき項目を減らすことと考えられる。
（そもそも無印版でもImmediate Mode Functionsは不要なのではないかと思うが。。。）
MISRA-C対応
MISRA-Cとは、主に自動車業界で準拠を求められるコーディング規約のこと。
ここでのMISRA-C対応とは、Khronosが提供するheader fileがMISRA-Cに準拠するように対応したということ。
具体的には、enumをdefineに変え、union(vx_pixel_value_t)を使うときは中の型を表すtagを持つようにしたらしい。
らしいというのは、SC版のheader fileが見つからなかったため、確認できなかったから。
ポインタ渡し時のサイズ情報の追加
サイズなしでポインタだけ渡すAPIがあったので修正したらしい。
具体的にどの関数のことかは不明。header fileがあれば。。。
機能要件IDの追加
仕様書に記載された機能ごとに[R#####]という機能要件IDを付与している。
この変更の目的は、機能安全規格で要求されるトレーサビリティを確保すること。
マクロ・定数の仕様追加
そのままだが、マクロ・定数の仕様が追加されている。
この変更の目的はおそらく、これらの仕様を機能安全規格で要求される詳細仕様として利用することと考えられる。
参考
まとめ・雑感
基本的には、機能安全対応は大変だから考慮すべきことをできるだけ減らしましょうというアプローチ。
それに併せて仕様の段階で共通して機能安全対応できるところはしようとしているように感じた。
なんにせよ、機能安全も含め仕様で考慮してくれるのはとてもありがたい。
どのように機能安全対応するかがベンダー依存だと、結局APIがベンダーごとにバラバラになってしまうことが容易に想像できるからだ。
ただ、どういった議論を経てこのような仕様になったのかもぜひ知りたい。
仕様策定メンバーになれれば一番いいのだろうが。。。
あと今回差分を洗い出しながら、SC版と無印版を一本化して欲しいなぁと思っていたら、EVSで「1.3からSCを取り込むことを検討中」と発表していた。ぜひ実現して欲しい。