具体的にはどのような機能安全対策が取られているのか?

続いて話は機能安全の話に。Functional Safetyとして知られるこの機能は、単に自動車だけでなく安全性が必要とされる多くの場所で必要な要件とされている。この分野は、必要とされるリソース(設計・検証や要求されるドキュメントなど)が桁違いに大きくなるので、敢えてこの分野はやらないと公言しているメーカーもあるほどだが、ARMはここに積極的にアドレスする事を宣言している(Photo10)。

Photo10:といっても、これをやるといい始めたのは割と最近の話で、実際Cortex-Rにしても当初からこういう用途は想定しつつ、しかし機能安全までは踏み込んでいなかった。

では自動車における機能安全とはなにか?という一例がこれ(Photo11)。パワーステアリング周りの操作に関しては、故障しないのが勿論一番ではあるが、工業製品ではそれはありえない訳で、では故障したらどう対処できるかをちゃんと考えておく必要がある。一番まずいのはECUが故障したりトルクセンサーが異常を出したりしたときに、パワーステアリング用モーターが固着してしまうことで、したがってこういう事態にならないような設計が必要になるわけだが、そもそも大前提として故障頻度をどの程度に抑えるかという話がある。故障しても事故にならない設計をするのと同様に、コンポーネント内部に関しても「回路の一部が異常をきたしても、直ぐに全体が故障しない」様な設計が求められる。

Photo11:機能安全の場合、どのレベルが必要かというのは部位によって異なる。この例に出てくるステアリング周りは、故障したら命に関わる危険性がある部分だけに通常はASIL Dクラスが求められる。

こうした機能安全は、業界に応じて異なる標準化がなされているが(Photo12)、骨子となる部分は基本的には同じで、あとはマージンの取り方とかドキュメントの手法などに相違点がある(一部検証方法などの違いもあるが)程度。流石にARMとしてもこの全部に対応するのは無理であり、まずはAutomotive/Medical/Industrialといったあたりをターゲットにする形だ。

Photo12:当然業界ごとに少しづつ要件が異なる。例えば自動車向けの場合、かつては産業用となるIEC 61513に準拠する形で実装が行われていたが、これはやや過剰すぎる面があって、自動車向けにISO 26262として標準化が行われた。

具体的にはどんな形で?というのがこちら(Photo13,14)。外部からの放射線などの影響に対してはECCとかMultiple Latchなどの対策が有用だし、Systemaic faultsへの対策はDCLS(Dual-Core Lock Step)などが効果的である。これらを当初からCortex-Rシリーズでは設計に盛り込んでいる、という話である。ただ、単にこれらを設計に盛り込むならず、開発時点でのマネジメントのレベルからこれに配慮してドキュメント(Photo15)を用意すると共に、こうした機構の検証メカニズムを用意、さらにはパッケージとして提供することでメーカーのみならず開発の負荷を減らせる、というのが同社の説明であった。

Photo13:こちらはエラーの発生する要因をまとめたもの。Photo12で言えば、産業用とか自動車用は、Systematic faultsの要因が相対的に高く、Random Hardware faultsの比率は低い。ところが航空機用とか衛星用になると、外部からの放射線の影響が極端に大きくなるので、Random Hardware faultsの対策を強化しないと間に合わないなど、使われ方による影響は大きい。

Photo14:Cortex-Rの最初の製品であるCortex-R4でも、実は結構なエラー対策が施されている。

Photo15:実は一番面倒なのがドキュメント周りで、これは他の規格(例えばISO 9001とか)でも大体同じである。これをスクラッチから作るのではなく、ある程度の部分をARMが提供するため、Cortex-Rを利用した半導体ベンダーや、更にこれを採用して機器を設計するメーカーの負荷が減らせるという話である。