MISRA-C++:2008, CERT, IEC61508 など ソフトウエアテストのセミナー

当日のスライド、活発に行われた質疑応答を以下に公開しました。今後とも、ご意見・ご質問を介してご指導頂けると幸いです。

Prof. Mike Hennell 氏による IEC 61508とテストについての講演＜スライド＞

CERT C について
MISRA-C++:2008 について
IEC61508 について

＜CERT-C についての質疑応答＞

Q：CERT C セキュアコーディングスタンダードは、どのバージョンのC言語標準を対象に書かれているのか？

　A：C99 [ISO/IEC 9899:1999] および C99以降のテクニカルレポート(たとえば TR 24731-1)をターゲットにして書かれている。C89 や K&R との違いについても適宜言及している。

Q：CERT C セキュアコーディングスタンダードで特定のCPUに関して記述しているか？

　A：No. 処理系依存の記述としては、OS として、POSIX準拠のOS, Windows, Linux などについて記述している箇所は存在する。

＜MISRA-C++：2008 についての質疑応答＞

Q：MISRA－C++ 2008 策定に関わられたクリスさんに。プログラマの負荷削減を考慮に入れたとの事であるが、どのようなことで？

　A：ツールでチェックできるものはツールでチェックさせようという考え。そうしないとコードのレビューが全て人間の作業となってしまうので。自分でやらなければならないので。しかしながら恐らくツールを使うにあたっては、そのために必要な作業にも興味があるでしょう。個人的経験では、一旦プログラミングスタンダードに準拠することを念頭にし、そのようなコードが書けるようになれば、あとは自動的にそのような作業は身に付く。コーディングしながらそのようなツールに普段からアクセスできれば、プログラマの作業削減につながる。

Q：MISRA適合調査中。認証機関は存在するか？

　A：今のところ存在しない。

Q：どう証明するか？文書化のフォーマットなどや指標など？

　A：MISRAのドキュメント内に、何が含まれるべきかの基本的な例はある。ただ具体例を示すのは難しいと考えている。プロジェクトごとで要件は変わるので（例えば安全性のレベル）。文書化で含まれるべき情報は、特定のルールに従えない場合の、その正当な理由。そして同時に、そのことにより安全性の問題が無いことの説明。そしてマネージャ、セキュリティオフィサーの承認を得ていることを証明できることも必要。

Q：ツールを用いてコードを解析したい。自分たちが書いたコードは何とかなるが、ツールが生成するコードなどにMISRAのエラーが出た場合、手を入れるべき？

　A：プロジェクトのSILレベルなど状況によるかと思われるので、一概には言えない。コード生成の内容にもよるが、テンプレートなどなら手を入れたほうが良いかもしれない。

Q：同上、OSやそのライブラリは？

　A：安全性を監査するセーフティオフィサーに相談すると良いのでは？レベルなど状況によって、求められる内容は異なるので、一般的な回答は難しい。OSのメーカーによっては、SILに応じて設計されたOSを提供しているので、それらを採用すればエビデンスの入手なども可能。

＜IEC61508 についての質疑応答＞

Q：スライド 11で、LDRAテストツールによる形式手法が紹介されているが、一般に形式手法は莫大な時間が掛かるものと思う。LDRAツールは自身の形式手法でテストしているか。その場合、どのくらいの時間が掛かっているのか。

　A：掛かる時間は解析対象コードサイズに依存。10万行程度なら5分くらい。想像されていることとは異なり驚かれるかもしれませんが、形式手法には様々な手法があり、弊社で取り入れているものは、解析時間が早いものを取り入れている。LDRA/Testbed のコードは、これらの解析を1日2回通している。

Q：スライド 12で紹介されている、3つのシステムワイドな複雑度解析（コントロールフロー、プログラミング構造、データフロー）とは？　McCabe の複雑度などとは異なるのか？

　A：LDRAテストツールでは、あらゆる複雑度解析を行っており、McCabe も組み込まれている。それらの解析結果を包括して、システムワイドな複雑度を３つの指標（コントロールフロー、プログラミング構造、データフロー）で解析できることを、このスライドで紹介している。


Q：流用性が無さそうなモジュールに対して複雑度解析をする意味があるのか？

　A：IEC61508では、システム全てに対して複雑度解析が必要。LDRA テストツールとしては、一部分でも、全体でも解析できる。また、特定コードを除外することもできる。例えば、MSのファンデーションクラスを対象から外すことができる。
仮にソフトウエアがプロジェクトで使われていない場合には、外さない理由は無いですね。

Q：LDRAでは色々の（静的～動的）解析機能があるようだが、開発の各工程でどれをどう使うと良いでしょう。お勧めの使い方など。

　A：たとえば弊社ツールで採用している形式手法は、コーディングが完了してからの利用がお勧め。ツールを初期の段階から活用するのなら、要件解析からで、テストベクタ生成に使う。そしてトレーサビリティのために、要件をデザインレベルに合わせていくつかに分解するといった目的に用いる。

Q：形式手法はシステムワイドに解析するので、一通りのコーディングが終わってから行うのか？その他の静的解析は、各プログラマが個々に日々行うものという理解で正しいか？

　A：形式手法は、LDRAテストツールの静的解析の肝（特にシステムワイドな解析は他製品には無い特徴）。プロシジャに10行追加したとしてもそれが効く。もしプロシジャのみに適応した場合、例えばグローバル変数は分からないので、解析能力全てを享受できない。システムワイド全体なら、全てが視覚的になり、よりシャープで正確な解析になる。

＜動的デモ、ターゲットHW、要件トレーサビリティ などについての質疑応答＞

Q：カスタマイズについて。個々の開発現場でツールの組合せなど異なるが、LDRAツールを利用するために必要な統合作業はどのようなものになるか？

　A：動的テストの実行支援ツールであるTBrunでは、コンパイラ、RTOS、ターゲットMPU環境など、あらゆる環境へのサポートができる仕組みを提供している。コンパイラの各種コマンド、実行環境のスクリプトなど。国内では富士設備により、これらの統合作業をサポートしている。難しいものではなく、一度経験されれば次の環境ではお客様自身で統合することも可能。また、そのような時は通常のサポートの範疇で対応もしている。

　作業内容の概説書に興味いただける場合は、別途ご要求ください。

Q：カスタマイズについて。静的解析のルール、インハウススタンダードの対応。

　A：LDRAでは、業界のあらゆるプログラミングスタンダードをサポート。それらの中から、必要なものだけを選りすぐった独自のスタンダードは、容易に組み上げることができるようになっている。また、ユニークな予約語なども、ユーザ側で簡単に変更できるようになっている。

まだサポートしていないルールなどは、お客様から指摘くだされば喜んで追加している（ツールでは不可能なルールを除いて）。また、よほど特別なケースで無い限り、費用を頂くこともない。LDRAテストツールは、30年以上に渡って顧客の必要とする機能を追加することで成長してきているので。

＜全体についての質疑応答＞

Q：LDRA のツールにも、MISRA-C++：2008 のルールを適応しているか。

　A：ツールはあまりC++使ってない。歴史が長いので。Cがベースであることを前提に。
特定のスタンダードを想定してコーディングしていないと、遵守は難しい。MISRAのドキュメントの中でも、既に書かれたコードに対してMISRAのルールを適応することは、あまり良い考えではないという記述・セクションがある。既存のコードにルールを適応させるとかなり沢山の違反が出るであろうが、それらは安全性に影響しないものも多くなる。レガシーコードに対してMISRAを適応させてみたい場合、どういうふうに実施していくかのポリシーを設ける、例えばあるファイルの30％以上に変更を加える場合とか。あるいは、一定のルールからの逸脱を認めるなど。例えばMISRAには、特定のタイプ名を使うというルールがあるが、それによってあらゆるファイルの書き換えが必要になるならば、それは対象外にするほうが良い。ルールの逸脱も時には許可される必要がある。

Q：C++が組込みで拡がってきた事情。どういうアプリケーションで？

　A：32ビット以上のMPUを用いたターゲット。コンパイラの効率改善。小さめのシステムで多く使われるようになってきている。アプリにも依存。小型マイコンを用いたシステムでは、アプリケーションはシンプルなものが多い。複雑なシステムではないため、C++である必要は無いでしょう。エアバスのA380,ロールスロイス社のジェットエンジン、ロッキード・マーチン社の F35 などで、採用されている。これら航空・防衛では、以前　Ada が採用されていたが実装できるエンジニアが少ないため、C++が求められるようになってきている。

Q：レガシーでいっぱいエラーが出る。レガシーコードに手を入れた場合。追加したコードはMISRA準拠したい。

　A：チェックをプロシジャー単位、ファイル単位、システム全体で範囲を決めて解析できる。取りあえずは全体に対して解析を行い、レポート時にフィルターをかける（例えばIPA/SECのルール違反、MISRAに対するルール違反など）、追加したエリアのみ対象にする。そうすることで、追加した以外の部分からの情報を得たシステムワイドな解析結果が得られるので、より良い解析情報を得ることができる。TBVision により、障害やセキュリティ脆弱性の高い部分のみ（レベルに応じて）抽出することもできる。

　MISRA-C++:2008 のチェアマンである Chris Tapp氏、DO-178B、IEC61508 など高信頼性ソフトウエアテストに貢献を続ける Mike Hennell 氏の来日に合わせて、ソフトウエアテストのセミナーを企画しました。また、JPCERTコーディネーションセンターから セキュアコーディングへの取組み、CERT C スタンダードの紹介も予定しています。

　画像クリックで拡大
■ソフトウエアテストのセミナー（定員８０）

　◇日時：2009年5月18日(月) 午後1時00分～5時00分 予定
　◇参加費無料（事前登録制） ◇会場：秋葉原コンベンションホール　５F 会場 ５A　http://www.akibahall.jp/data/access.html

■内容

　コストを削減し、開発チームの負担を削減するために、ソフトウエア開発ライフサイクルの各種フェーズをサポートする、自動ソフトウエア検証プロセスが求められています。
最新の国際標準である MISRA-C++:2008、CERT C、IEC61508 の話題を中心に、静的解析技術と、動的解析技術を融合し、要件からのトレーサビリティをサポートすることで、ソフトウエア開発ライフサイクルの各種検証作業の自動化を一貫して支援できることを紹介します。

　- LDRA 概要　（5～10分程度）
　- CERT C について　（1時間）
　- MISRA-C++:2008 について　（1時間）
　　　＊必要となった背景
　　　＊開発経緯
　　　＊主要な機能、効果
　　　＊今後の予定
　- デモ/ コーディングスタンダード解析　（10分程度）
　- IEC61508 の５つの推奨とその課題について　（1時間）
　　　＊Formal proof　形式的証明
　　　＊Probabilistic testing　確率論的テスト（ランダムテストなど）
　　　＊Static analysis　静的解析
　　　＊Dynamic analysis and testing　動的テストとその解析
　　　＊Software complexity metrics　ソフトウエア複雑度の尺度
　- デモ/ 静的解析と動的解析の融合、要件からのトレーサビリティ　（20～30分）
　- Q&A

　日本語版『CERT C セキュアコーディングスタンダード』は、JPCERTコーディネーションセンター、セキュアコーディングプロジェクトにより翻訳されて、以下に公開されています。

http://www.jpcert.or.jp/sc-rules/

■講師紹介

　＊JPCERTコーディネーションセンター、セキュアコーディングプロジェクトから、『CERT C セキュアコーディングスタンダード』の訳者をお招きしています

　＊Mike Hennell 氏　LDRA社を設立　最高技術責任者　
　　　各種テスト手法の考案や、DO-178B、MISRA、IEC61508 など、高信頼性ソフトウエアテストに関わる多くの貢献をしています。

　＊Chris Tapp 氏　LDRA社エンジニア
　　　MISRA-C++委員会のチェアマン、また CERT C にも貢献しています。

■お申し込み方法
　下記の内容をご記入の上、E-mail にてお申し込みください。

　” お名前、会社名、部署名、住所、電話、E-mailアドレス ”

■LDRA は、ソフトウエアテスト自動化支援ツールです。

　LDRA tool suite は、ソフトウエア検証の全工程を完全にサポートする初めての自動化支援ツールです。要件管理と統合され、要件解析から静的解析・動的テストとその結果解析などソフトウエア開発に関わる全ての工程に対するテスト、検証、トレーサビリティが支援されます。異業種のプログラミング標準を多角的にサポートし、あらゆる組込みシステムターゲット環境をサポートしています。

70％にも及ぶプロジェクトの失敗は、要件管理とそのトレーサビリティに起因すると報告されており、ソフトウエア開発ライフサイクルに亘って要件管理をすることは、この不況下においてのコスト削減策の決定打となり得ます。要件管理をTBreq を介してLDRA tool suiteに統合することで、その次世代型の管理と完全な自動化要件トレーサビリティにより、ソフトウエアのエラー、開発コスト、リソースの制約が削減されます。TBreqにより、要件、コードモジュール、検証成果物（静的解析、動的解析、ユニット・システムレベルテストなど）の関連付けを取り、非公式な変更やテスト結果も記録され、それら変更による影響を受ける要件はハイライトできることで、全開発チームメンバーは追加検証が必要となるコード・データ領域を特定することができるようになります。

LDRA社は、あらゆる国際的な業界標準をサポートしています。例えば LDRA DO-178B tool qualificationサポートパッケージでは、FAA’s DO-178B levels C, B and Aで求められるソフトウエアの全工程に対する認証作業を支援しています。この FAA’s DO-178Bは、今や航空宇宙以外の、自動車、医療機器、原子力関連など安全性、機能性を求められるシステムにおいてベストプラクティスな方法論として注目され、参考にされています。

LDRA テストツール情報は、こちらから