3.10

View in English

3.10 組込みシステムとリアルタイムシステム

概要と動機

組込みシステムとは、汎用のコンピュータではなく、デバイス上で動くソフトウェアです。自動車、ペースメーカー、サーモスタット、工場のロボット、誘導装置の中に住んでいます。ソフトウェアはそのデバイス専用で、デバイスには通常、メモリ、処理能力、エネルギーに厳しい制約があります。クラウドのコンソールでボタンをクリックして、常にリソースを追加できるわけではありません。出荷したものが、しばしば何年も動くものです。

リアルタイムシステムとは、正しさが、正しい答えを出すことだけでなく、タイミングにも依存するシステムです。完璧な展開コマンドを1秒遅れて計算したエアバッグのコントローラーは、完全に失敗しています。リアルタイムの仕事は、あらゆるタスクに難しい問いを加えます。これは最悪の場合でも、毎回、締め切りまでに終わるか。これは、ウェブやクラウドのソフトウェアに一般的なスループット優先の考え方とは異なる規律です。

大きな組織にとって、これは最初に見える以上に重要です。企業は、コネクテッドカー、医療機器、産業用コントローラー、何十億ものモノのインターネット(IoT)デバイスを作ります。政府は、防衛のプラットフォーム、航空電子機器、電力網のコントローラー、医療の規制を運用します。これらの領域では、ソフトウェアの欠陥が人を傷つけ、生産ラインを止め、国家の安全を損ないえます。ここでのルールはより厳しく、テストはより難しく、標準は法的に拘束力があります。本章は、本物の制約のもとで、正しく、タイムリーで、安全で、セキュアなソフトウェアを築く助けになります。ソフトウェア構築(2.9章)、分散システム(3.3章)、スケーラビリティと性能(3.5章)、インフラとクラウドのセキュリティ(4.3章)、ソフトウェア保守(3.7章)につながります。

主要原則

  • タイミングは正しさの要件であり、あれば嬉しい性能ではない。 遅れた答えは、間違った答えでありえます。
  • 平均的な場合ではなく、最悪の場合のために設計する。 リアルタイムの保証は、典型的な速度ではなく、最悪の場合の振る舞いに拠ります。
  • 決定性は生の速度に勝る。 常に締め切りを守る予測可能なシステムは、ときどき外す、より速いものに勝ります。
  • リソースは有限で固定されている。 お金を予算化するのと同じくらい意図して、メモリ、CPUサイクル、エネルギーを予算化します。
  • 安全とセキュリティは作り込むものであり、後から加えるものではない。 規制された領域では、品質を主張するだけでなく、仕事を示さなければなりません。
  • ハードウェアはシステムの一部である。 チップ、センサー、物理を推論せずに、ソフトウェアを推論することはできません。
  • フィールドでの更新は、後付けではなく、ライフサイクルの能力である。 世界にあるデバイスには、修正を受け取る安全な方法が必要です。

推奨事項

各タイミング要件を、ハード、ファーム、ソフトに分類する

すべての締め切りが等しいわけではありません。ハードリアルタイムの締め切りは、外すとシステムの失敗や害を引き起こすので、決して外してはなりません。エンジン制御や操縦翼面を考えてください。ファームの締め切りは、まれな外れを許容しますが、遅れた結果は役に立たず捨てられます。ソフトリアルタイムの締め切りは、価値を穏やかに劣化させます。わずかに遅れて届いた動画のフレームは品質を下げますが、災害は起こしません。労力、テストの厳密さ、コストが大きく異なるので、タイミングに敏感なすべてのタスクにそのクラスをラベル付けしてください。二つの性質がタイミングの振る舞いを記述します。レイテンシは、イベントと応答の間の遅延です。ジッターは、そのレイテンシの、一回から次への変動です。ハードリアルタイムのシステムは、レイテンシを下げることと同じくらい、ジッターに上限を課すことを気にします。予測可能性こそが、締め切りが常に守られることを証明できるようにするものだからです。

実行の基盤を意図して選ぶ: RTOSかベアメタルか

主な基盤は二つあります。ベアメタルのファームウェアは、オペレーティングシステムなしにハードウェア上で直接動き、単純なループと割り込みハンドラを使います。最小で最も予測可能な選択肢で、一つの明確な仕事を持つ小さなデバイスに合います。リアルタイムオペレーティングシステム(RTOS)は、優先度でタスクをスケジュールし、タイミングの上限を保証する小さなオペレーティングシステムです。タイミングを予測可能に保ちながら、複数のタスク、スケジューラ、タイマーやメッセージキューのようなサービスを与えます。異なる締め切りを持つ複数の並行タスクがあるときは、RTOSを選びます。デバイスが非常に制約されているときや、タイミングが証明可能に単純でなければならないときは、ベアメタルを選びます。ハードリアルタイムの仕事には、プリエンプティブな優先度ベースのスケジューラを好み、タスクの頻度で優先度を割り当て、タスクの集合がスケジュール可能であることを証明できるレートモノトニックスケジューリングのような手法で解析します。

メモリ、CPU、電力を第一級のリソースとして予算化する

乏しい各リソースを、硬い天井を持つ予算として扱います。メモリには、ヒープ上の動的割り当てよりも静的割り当てを好みます。動的メモリは断片化し、最悪の瞬間に予測できない形で失敗しうるからです。多くの安全規格は、まさにこの理由で、起動後のヒープの使用を制限または禁止しています。CPUについては、最悪実行時間(WCET)、つまりタスクがかかりうる最長の時間を測定し、平均ではなくその数字に対してスケジュールします。電力については、多くのデバイスが電池で動くかエネルギーを収穫することを忘れないでください。何か月も何年も持たなければならないエネルギー予算を達成するよう、デューティサイクル、スリープ状態、ウェイクアップのイベントを設計します。これらの予算を書き留め、他の要求と同じようにレビューします。

割り込みと並行性を厳格な規律で扱う

割り込みは、現在の仕事を一時停止してハンドラを即座に実行する、ハードウェアの信号です。割り込みはデバイスが世界に即座に反応する方法であり、微妙なバグの主要な源です。ハンドラを可能な限り短く保ちます。イベントを確認し、最小限のデータを退避し、本当の仕事は通常のタスクに先送りします。割り込みはどの二つの命令の間でも発火しうるので、共有データを競合状態から注意深く守らなければなりません。ロックフリーの技法、短いクリティカルセクション、よく理解されたプリミティブを使い、低優先度のタスクがロックを持って高優先度のタスクをブロックする優先度逆転を防ぎます。この並行性は3.3章の推論を共有しますが、タイミングはより厳しく、リトライの余地はありません。

ハードウェアの詳細を隔離するデバイスドライバを書く

デバイスドライバは、特定のハードウェアの一部(センサー、無線、モーターコントローラー)と話すソフトウェア層です。ハードウェア固有のコードをきれいなインターフェースの背後に保ち、残りのソフトウェアが、レジスタのアドレスではなく、安定した抽象に依存するようにします。これにより、コードはターゲット外でテスト可能になり、チップが在庫切れになったときに移植しやすくなり、推論も単純になります。タイミング、バイトオーダー、ハードウェアの癖についてのすべての仮定を文書化してください。これらこそが、現場の失敗を引き起こす詳細だからです。これは、間違ったビット一つがモーターを止めうる所に適用された、2.9章の構築の規律です。

領域を統べる機能安全の標準を採用する

デバイスが人や財産を傷つけうるなら、機能安全の標準がおそらく適用され、それはしばしば法律です。IEC 61508は電子システムの安全の一般的な標準で、他のいくつかの親です。ISO 26262は道路車両の安全を統べます。DO-178Cは民間航空の機上ソフトウェアを統べます。IEC 62304は医療機器ソフトウェアを統べます。コーディングには、MISRA Cが、危険なC言語の機能を制限してコードをより安全で解析しやすくする、広く使われるルールの集合です。これらの標準は、要求からコード、テストまでのトレーサビリティ、定義されたプロセス、監査人や規制当局に渡せる証拠を要求します。適切なものを早期に採用してください。後から証拠の跡を後付けするのは苦痛で、ときに不可能だからです。

シミュレーションとハードウェアインザループでテストする

組込みソフトウェアは、ウェブアプリをテストするようには、テストできません。層をなす戦略を築きます。ハードウェア抽象インターフェースに対して、通常のコンピュータでユニットテストを実行します。実際のハードウェアが乏しい、あるいは動かすのが危険なときは、シミュレーションでデバイスとその環境をモデル化します。それからハードウェアインザループ(HIL)テストを使います。本物のコントローラーが、それが制御する物理システムのシミュレーション版に対して動くので、固着したセンサーや突然の負荷のような故障条件を、安全にテストできます。これらのテストをパイプラインで自動化し、すべての変更がデバイスに届く前に、現実的な条件で確認されるようにします。

最初の日から、無線更新(OTA)とデバイスのセキュリティを設計する

フィールドのデバイスには修正が必要になるので、無線更新(OTA)、つまりネットワーク経由で新しいファームウェアを安全に届ける方法を計画します。安全なOTAの設計は、各更新に暗号署名し、インストールの前に署名を検証し、原子的に更新し、新しいものの起動が失敗したら既知の良いイメージにロールバックできます。これを、制約されたハードウェアに適応させた4.3章のセキュリティ原則と組み合わせます。ハードウェアの信頼の起点とセキュアブートを使い、署名されたファームウェアだけが動くようにします。転送中と保存時のデータを暗号化します。既定の認証情報を変更し、使わないインターフェースを無効にします。IoTのフリートは、巨大な攻撃面を持つ分散システムであり、弱い既定のパスワード一つが、何百万ものデバイスを一度に侵害しえます。

トレードオフ: 長所と短所

選択長所短所 / コスト
RTOSマルチタスク、優先度スケジューリング、タイミングのサービスオーバーヘッド、大きなフットプリント、学習曲線
ベアメタル最小、最も予測可能、完全な制御多くのタスクにスケールするのが難しい、手作業が多い
静的割り当て予測可能、断片化なし、安全に優しい柔軟性が低い、すべてを前もってサイズ決定しなければならない
正式な安全認証法的な市場アクセス、厳格な証拠、高い信頼時間とお金の大きなコスト、反復が遅い
OTA更新フィールドのデバイスを直し改善し、寿命を延ばす更新のインフラ、セキュリティの負担、ロールバックのリスク

最上位のトレードオフは、予測可能性と柔軟性の間にあります。汎用システムを便利にするすべて(動的メモリ、バックグラウンドのガベージコレクション、ベストエフォートのスケジューリング、弾力的なリソース)は、タスクが固定されたフットプリントの中で常に時間どおりに終わるという保証に反して働きます。組込みとリアルタイムのエンジニアリングは、決定性と安全を買うために、意図して柔軟性を手放します。スキルは、締め切りやリスクが本当に要求する所でのみその取引を使い、柔軟で速く動く部分(デバイスのクラウドのバックエンドのような)を、きれいな境界の向こう側に保つことです。

チームで議論すべき問い

  1. タイミングが重要な経路で、平均のレイテンシだけでなく、ジッターを測定していますか。 ハードリアルタイムの正しさは、典型的なレイテンシを下げることだけでなく、応答時間の変動(ジッター)に上限を課すことに拠ります。予測可能性こそが、締め切りが常に守られることを証明できるようにするものだからです。低い平均だがときどき大きなスパイクのある制御ループは、それでも締め切りを外して害を引き起こしえ、平均はそれを隠します。タイミングが重要な各タスクについて、最悪の場合を含むばらつきの測定値を持ち込み、外した結果に合わせてテストの厳密さが決まるよう、それぞれをハード、ファーム、ソフトとラベル付けしてください。汎用システムで便利なすべて(動的メモリ、ガベージコレクション、ベストエフォートのスケジューリング)は予測可能性を攻撃するので、ハードな経路の外に置きます。平均しか報告しないなら、ハードな締め切りが守られていると誠実には主張できません。

  2. RTOSかベアメタルかの選択は今も正しく、タスクの集合がスケジュール可能であることを証明できますか。 実行の基盤は、デバイスが育つにつれて見直す決定です。ベアメタルは一つの明確な仕事には最小で最も予測可能ですが、RTOSは、異なる締め切りを持つ複数の並行タスクがあるときにそのオーバーヘッドの元を取ります。ハードリアルタイムの仕事には、本章は、タスクが収まることを願うのではなく証明できる、レートモノトニックスケジューリングのような手法で解析される、プリエンプティブな優先度ベースのスケジューラを指します。現在のタスクの集合、その頻度、最悪実行時間を持ち込み、スケジュール可能性が実際に成り立っているか、それとも基盤が保証できる範囲を超えてタスクが静かに積み上がっていないかを確認してください。低優先度のタスクがロックを持って高優先度のものを止める優先度逆転を防ぎます。タスクの集合ではなく習慣で基盤を選ぶことが、タイミングの保証が静かに浸食される道です。

  3. 決定的なデバイスと柔軟なクラウドのバックエンドの境界はどこにあり、片側で速く動いてもう片側を危険にさらさないほどきれいですか。 本章の最上位のトレードオフは、決定性と安全を買うために柔軟性を手放すもので、スキルは、締め切りやリスクが本当に要求する所でのみその取引を使うことです。きれいな境界により、安全が重要なファームウェアは保守的で認証されたままでいられ、クラウドのバックエンドは素早く反復でき、両者がそれぞれの安全なペースで進化します。アーキテクチャを持ち込み、その継ぎ目を見つけてください。決定的であることを証明し、署名され検証された経路で更新しなければならないものと、サーバーで毎週変更してよいもの。線をぼかすと、クラウド風の習慣(動的割り当て、ベストエフォートのタイミング)が制御の経路に引きずり込まれるか、バックエンドがファームウェアの周期まで不必要に遅くなります。境界を正しくすることが、安全の証拠とデリバリーの速度の両方を保つものです。

  4. 各製品を統べる機能安全の標準はどれで、現在の証拠は、監査人が受け入れるものからどれだけ離れていますか。 標準(IEC 61508、道路車両のISO 26262、機上ソフトウェアのDO-178C、医療機器のIEC 62304)はしばしば法律であり、最後に偽造できない、要求からコード、テストまでのトレーサビリティを要求します。大きなチームにとってリスクは、グループが証拠の跡を不均一に採用することです。ある製品ラインは監査に備えがあるのに、別のラインは認証の途中で、要求が一度もトレースされていなかったことを発見します。相反する引力は速度です。完全なトレーサビリティとMISRA Cの徹底は日々の反復を遅くし、締め切りの圧力のもとのチームは、「後で」まで証拠を先送りしたくなります。現在のトレーサビリティマトリクス、まだ未解決の静的解析の指摘、目標とする保証水準に対する誠実なギャップ分析を持ち込んでください。企業や政府の文脈では、認証のリードタイムと監査人の期待を加えてください。設計の後に証拠を後付けするのは遅く、高価で、ときに不可能で、認証の遅れは市場アクセスを完全にブロックしえるからです。

  5. フィールドのデバイスで深刻な欠陥が明日見つかったら、フリート全体にわたって、どれだけ速く安全に直せ、ロールバックをリハーサルしましたか。 パッチを当てられないデバイスは、恒久的な安全とセキュリティの負債になり、物理的なリコールは、署名された無線更新より桁違いにコストがかかります。緊張は、不注意な更新の仕組みがそれ自体攻撃面であり、ブリック化のリスクがあることです。署名されていないイメージをインストールするOTAの経路や、悪い起動をロールバックできないものは、一つの悪いリリースを何百万もの死んだユニットに変ええます。更新の設計(暗号署名、インストール前の署名検証、原子的なインストール、既知の良いイメージへの自動ロールバック)、セキュアブートとハードウェアの信頼の起点の状況、そして最後に誰かが本物のハードウェアで実際にロールバックを動かしたときを持ち込んでください。企業や公共のフリートでは、署名鍵の責任者と、侵害された鍵をどう失効させるかを加えてください。漏洩した鍵や共有の既定の認証情報は、フリート全体を一度に侵害しえるからです。

  6. メモリ、CPU、電力の予算は硬い上限とともに書き留められ、テスト戦略はシミュレーションと本物のハードウェアの両方を動かしますか。 リアルタイムの保証は、平均的な振る舞いではなく、最悪実行時間と固定されたリソースのフットプリントに拠るので、予算にない動的なヒープ割り当てや、テストされていない最悪の負荷は、決定性が静かに浸食される所です。大きなチームにとって危険はずれです。タスクが積み上がり、メモリが忍び寄り、数週間の稼働の後にデバイスが現場で失敗するまで、誰も予算を所有しません。トレードオフはカバレッジとコストです。固着したセンサーのような故障を注入するハードウェアインザループの装置は構築に高価ですが、純粋なシミュレーションは、本物のチップでしか現れないタイミングのバグを隠します。文書化された予算、それらに対する測定された最悪実行時間、パイプラインがリリースの前に、抽象層のユニットテスト、シミュレーション、ハードウェアインザループを実行している証拠を持ち込んでください。規制された政府の設定では、これを標準が求める構造的なテストカバレッジに結びつけてください。監査人は、平均の場合がよく見えたという保証ではなく、故障条件が実行された証明を求めるからです。

セクター別の視点

スタートアップ。 速度と生存が支配するので、軽量なRTOSか単純なベアメタルのループを選び、起動後の動的割り当てを禁じ、持っていない認証の予算を追うのではなく、唯一のクリティカルなループの最悪の場合の時間を測定してください。市場が強いない限り、正式な機能安全のプロセスは省きますが、自動ロールバックを伴う署名付きの無線更新は決して省かないでください。若い会社はフィールドのリコールを生き延びられず、リモートの修正は、悪い夜と死んだ製品の違いだからです。デバイスのファームウェアを小さく保守的に保ち、乏しいエンジニアが、負担できないパイプラインを保守しなくて済むようにします。

小規模事業者。 組込みの専門家はおらず、独自のスケジューラやブートローダーを作るのではなく、実績のあるモジュール、リファレンス設計、ベンダーのRTOSのディストリビューションに頼ってください。作るか買うかの選択を、今後十年にわたって誰がデバイスにパッチを当てるかを軸に枠づけます。頼れる買ったセキュリティと更新のスタックは、保守できる人が誰も残っていない特注のものに勝ります。既定のパスワード、開いたデバッグインターフェース、署名されていない更新を、あなたを傷つける可能性が最も高い失敗として扱ってください。防ぐのは安く、現場で発見するのは破滅的だからです。

大企業。 問題は、多くの製品ラインとチームにわたる一貫性です。共有の実行基盤の方針、共通のリソース予算のテンプレート、徹底されたMISRA Cと静的解析、そして各グループが再発明しないよう、認証された一つのOTA更新とセキュアブートのプラットフォーム。機能安全とハードウェアインザループの負担を明示的に予算化し、ハードウェア抽象インターフェースを標準化して、チップの在庫切れが製品を孤立させないようにし、フリートのタイミングの証拠、安全の成果物、セキュリティの姿勢を、チームごとの民間伝承ではなく、統治される資産として管理します。フリート全体での弱い既定の認証情報一つは、企業規模の負債なので、認証情報と鍵の管理を集中させてください。

政府。 調達規則、透明性、公的な説明責任があらゆる選択を形づくります。供給者に、機上、医療、防衛のソフトウェアを、危険に見合う保証水準で、統べる標準(DO-178C、IEC 62304、IEC 61508)に従って開発し、監査人がレビューするトレーサビリティと構造的カバレッジの証拠を引き渡すよう求めます。セキュアブート、ハードウェアの信頼の起点、管理された署名付きのフィールド更新プロセスを要求してください。飛行や電力網のシステムへの検証されていない更新は許容できないからです。ソース、安全の成果物への権利、第二の供給者で再認証できる能力を認める契約を好み、ベンダーが廃業しても、公衆が何十年も頼るシステムが孤立しないようにします。

事例

スタートアップ。 電池駆動の空気質モニターを作る小さなハードウェアスタートアップは、ファームウェアを、固定されたタスクの集合と起動後の動的割り当てなしの軽量なRTOS上に書くので、出荷されるデバイスは、コイン電池で何年も動くデバイスです。認証の予算がなくても、チームはセンサー読み取りループの最悪の場合の時間を測定し、リリースのたびに、ベンチの装置で注入した故障条件に対してユニットをテストします。自動ロールバックを伴う署名付きの無線更新により、出荷したすべてのユニットで欠陥を直せるので、現場での悪い読み取りが、若い会社が生き延びられないリコールを意味することはありません。

大企業。 コネクテッドカーのメーカーが、電子ブレーキのコントローラーを作ります。ハードリアルタイムの制御ループは、レートモノトニックスケジューリングと静的メモリを持つRTOS上で動き、すべてのタスクが測定された最悪実行時間を持ちます。チームは、要求からコード、テストまでの完全なトレーサビリティとともにISO 26262に従って開発し、すべてのコミットで静的解析によってMISRA Cを徹底します。ハードウェアインザループの装置が、ファームウェアが出荷される前に、注入されたセンサー故障を含む何千もの道路シナリオを再生します。署名付きのOTA更新により、会社は高価なリコールなしにフリート全体で欠陥を直せ、車が新しいイメージの起動に失敗したら自動的にロールバックします。

政府。 国の航空当局が、新しい飛行管理コンピュータを認証します。供給者は機上ソフトウェアを、危険に見合う保証水準でDO-178Cに従って開発し、監査人がレビューする、要求のカバレッジと構造的なテストカバレッジの証拠を作成します。タイミングは、割り込みのレイテンシに上限を課し、起動後の動的割り当てなしに、最悪の負荷のもとで決定的であることが証明されます。セキュアブートとハードウェアの信頼の起点が、署名され認証されたファームウェアだけが動くことを保証します。フィールドの更新は、管理された署名付きのプロセスに従います。飛行システムへの検証されていない更新は許容できないからです。

ビジネスケース: 動機、ROI、TCO

ビジネスケースは、失敗のコストと市場へのアクセスのコストに支配されます。規制された領域では、安全認証なしには製品をまったく売れないので、プロセスのコストは単に参入の代価です。それを超えて、フィールドのハードウェアの欠陥は、並外れて高価です。物理的なリコールはクラウドのホットフィックスよりはるかにコストがかかり、安全のインシデントは、製品ラインを終わらせうる責任、規制上の罰則、評判の傷を伴います。安全、決定性、更新可能性を最初から作り込むことは、現場でその不在を発見することに比べて安いのです。

投資収益を、避けられたリコール、より速い認証、より長いデバイスの寿命を軸に枠づけてください。堅牢なOTAの能力は、多くのリコールになったはずのものを低コストのリモートの修正に変え、避けられたリコール一つが、更新プログラム全体の元を取りえます。厳密なWCET解析とリソースの予算化により、自信を持ってより安いハードウェアで出荷でき、大きなフリート全体でユニットあたりのコストを下げます。総所有コストについては、これらのデバイスが何年も何十年も生きることを忘れないでください。保守、セキュリティパッチ、サポートの負担(3.7章)は、最初の構築をはるかに上回ります。更新可能性、明確なハードウェア抽象、文書化された予算のための設計が、その長い尾を手頃に保つものです。

アンチパターンと落とし穴

  • 平均的な場合のための最適化。 締め切りを「たいてい」守ることは、ハードリアルタイムの要求に失敗していることです。
  • 制御の経路での動的割り当て。 ヒープの断片化は、数週間の稼働の後にのみ現れる失敗を引き起こします。
  • 太った割り込みハンドラ。 割り込みの中に重い処理を置くと、タイミングの予算を吹き飛ばし、競合状態を生みます。
  • 監査まで標準を無視する。 後からトレーサビリティと証拠を後付けするのは、遅く、高価で、ときに不可能です。
  • 更新の経路なしに出荷する。 パッチを当てられないデバイスは、恒久的なセキュリティと安全の負債になります。
  • 既定のパスワードと開いたインターフェース。 弱い認証情報一つが、IoTのフリートをボットネットに変えます。
  • シミュレーターだけ、あるいはハードウェアだけでのテスト。 それぞれが、他方が捉えるバグを隠します。両方が必要です。
  • ハードウェアを他人の問題として扱う。 ここでは、タイミング、バイトオーダー、センサーの癖はソフトウェアの関心事です。

成熟度モデル

  • レベル1: 開始。 タイミングは解析されるのではなく、願われます。メモリは好きなように動的に割り当てられます。機能安全の標準には従わず、テストは手作業でオンデバイスのみです。デバイスは出荷後に更新できないので、フィールドの欠陥は、リコールか恒久的な負債を意味します。
  • レベル2: 発展。 一部のタスクには測定されたタイミングがあり、基本的なRTOSか構造化されたループがありますが、実践はチームごとに異なります。コーディングのガイドラインはありますが徹底されず、テストにはいくらかのシミュレーションがあります。手作業でリスクのある更新の経路が、一部の製品にはあり、他にはありません。良い習慣はありますが一貫せず、次の製品ラインがそれを引き継ぐ保証はありません。
  • レベル3: 標準化。 タイミング要件はハード、ファーム、ソフトに分類され、最悪実行時間とスケジュール可能性の手法で解析され、文書化されて組織全体で徹底されます。メモリ、CPU、電力のリソース予算は、硬い上限とともに書き留められます。統べる機能安全の標準は、要求からコード、テストまでのトレーサビリティとともに守られ、MISRA Cまたは同等のものが、すべてのコミットで静的解析によって徹底されます。ハードウェアインザループのテストはパイプラインで動きます。ロールバックを伴う署名付きで原子的な無線更新とセキュアブートが、あらゆる所で求められる基準です。
  • レベル4: 管理。 組織は組込みの資産を、ベースラインに対して測定し、制御します。最悪実行時間の余裕、ジッターの分布、締め切りの外れ率、メモリと電力の余裕、未解決の静的解析の指摘、認証の証拠のカバレッジ、無線更新の成功率とロールバック率を追跡し、合意された目標と比較します。リソースやタイミングの予算に対するずれは、デバイスが現場で失敗する前に行動を引き起こし、リリースの継続・中止の判断は、その場の判断ではなくこのデータに基づきます。管理者は、どの製品ラインが監査に備えがあり、どれが締め切りの逃しや予算の超過に向かっているかを見られます。
  • レベル5: オーケストレーション。 決定性、安全の証拠、セキュリティは、継続的に検証され自動化されています。故障の注入とハードウェアインザループがすべての変更で動き、認証の成果物はプロセスの副産物として生成されます。フリートは、長い運用寿命を通じて、規模で安全に監視され、パッチを当てられ、更新されます。組織は、チップが在庫切れになり、脅威が進化し、規制が変わるにつれて、実行の基盤、リソースの予算、標準の採用を適応させ、個々の危機にだけ反応するのではなく、証拠に基づいてデバイスのポートフォリオ全体を再均衡させます。

議論のためのアイデア

  1. デバイスのタスクのうち、本当にハードリアルタイムなのはどれで、それぞれが常に締め切りを守ることを証明できますか。
  2. 重要な制御ループの最悪実行時間を知っていますか。それとも平均だけですか。
  3. 製品を統べる機能安全の標準はどれで、現在の証拠は、それが要求するものからどれだけ離れていますか。
  4. フィールドのデバイスで深刻な欠陥が明日見つかったら、どう直し、どれだけ速く直せますか。
  5. 制御の経路のどこにまだ動的メモリの割り当てがあり、1000時間目にそれが失敗したら何が起こりますか。
  6. 共有の既定の認証情報を一つ見つけた攻撃者に、IoTのフリートはどう耐えますか。

要点

  • 組込みソフトウェアは制約されたハードウェア上で動き、リアルタイムの正しさは、正しい答えだけでなく、タイミングに拠ります。
  • 各締め切りをハード、ファーム、ソフトに分類し、最悪の場合のタイミング、上限のあるジッター、生の速度より決定性のために設計します。
  • RTOSかベアメタルかを意図して選び、メモリ、CPU、電力を固定された第一級のリソースとして予算化します。
  • 割り込みハンドラを小さく保ち、共有データを守り、ハードウェアをきれいでテスト可能なドライバのインターフェースの背後に隔離します。
  • 領域が求める機能安全の標準(IEC 61508、ISO 26262、DO-178C、IEC 62304、MISRA C)を、完全なトレーサビリティとともに早期に採用します。
  • シミュレーションとハードウェアインザループでテストし、安全で署名付きでロールバック可能なOTA更新とデバイスのセキュリティを最初の日から築きます。

参考文献とさらなる読み物

  • IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems
  • ISO 26262, Road Vehicles: Functional Safety
  • RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification
  • IEC 62304, Medical Device Software: Software Life Cycle Processes
  • MISRA, MISRA C: Guidelines for the Use of the C Language in Critical Systems
  • Michael Barr and Anthony Massa, Programming Embedded Systems
  • Elecia White, Making Embedded Systems
  • Jane W. S. Liu, Real-Time Systems
  • Giorgio Buttazzo, Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications
  • Colin Walls, Embedded Software: The Works
  • Philip Koopman, Better Embedded System Software
  • OWASP Internet of Things (IoT) security guidance