MISRA C/CERT Cに準拠したソフトを自動車メーカーへ納入する

■はじめに(読んでほしい人)

・MISRA C、CERT Cについて知りたい人
・自動車向けソフトを作っている人
・C言語が好きな人

この記事で扱うC言語とはC99のことです。また、MISRA CはMISRA C:2012、MISRA compliance 2016です。2004はあつかいません。

私はソフトエンジニアとして自動車ECUのソフト開発に携わっております。
MISRA-C/CERT-Cの準拠状況について、お客さん(自動車メーカー)へ報告をしたり、コードを見せて説明したりが今の主なお仕事。

■準拠するソフトを作ることの難しさ
"MISRAに準拠"、"CERTに準拠"とあちこちで効かれますが、そもそも準拠しているってどんな状態？

・お客さん(自動車メーカー)が準拠しているか判断する

これが一番しんどい。結局の所、お客さんがいいよって言わないとどんなソフトも非準拠。いろんな説明を付けて煙にまいて、お客さんを納得させるのです！

■まずは資料提出
何度目かのソフトリリースを乗り越えて、そろそろ製品版の納入時期。開発も目処がついて一安心。そんなころにMISRA C/CERT Cの準拠確認イベントが発生します。
MISRA compliance 2016に従った資料をなんとか用意しいざ提出。
メーカのC言語(MISRA C)詳しいおじさんからGEP,GRPについてのツッコミをいただきます。

■GEP,GRPへのつっこみ
GEP,GRPに書くことは概ねこんな感じ

・ソフトの情報(コンパイラ、言語規格)
・ツールの情報(ソフト名、バージョン、オプション)
・ルールの一覧(MISRA C:2012,CERT C)
・ツールの解析できる/できないの情報
・ツールで解析できない場合の確認方法

私のプロジェクトではQACというソフトを使って解析を行いました。MISRA CにもCERT Cにも対応するスグレモノ。ただし、全部に対応していないところが曲者。早く全部に対応してくれ。
ツールで解析できない箇所についてどのように準拠するようにするのかについて詳しく確認されます。社内の開発ルールで決まっていたり、レビューのチェックリストで確認したりということを一つずつ丁寧に紐付けて、漏れがないことをメーカーと確認します。
MISRA C/CERT Cを前提とした開発ルールであれば問題ないですが、そうでない場合はいくつかのルールが100%漏れています。事前に確認して、開発ルールを後から変更しておきましょう。これでGRP,GEPは完璧です。

■GCS,逸脱記録,逸脱許可へのつっこみ
それぞれこんなことが書かれています

・GCS : ルールごとの準拠結果(当然全て準拠)
・逸脱記録 : どうしても違反しないと行けない理由のリスト
・逸脱許可 : 違反してもいい場合を事前に決めたリスト

準拠結果は４段階。準拠/逸脱あり/違反/非適用。QACの解析結果で警告が出なかったものは"準拠"、警告が出たかつRequired(必要)の場合は逸脱記録を作成して"逸脱あり"、警告が出たかつAdvisory(推奨)の場合は"違反"、GRPで未採用としたルールがある場合は"非適用"です。
Mandatory(必須)は修正しておいてください。Required(必要)は修正不要ですが逸脱記録を必ず作成してください。
ただし４つの場合に該当する場合のみしか逸脱記録は認められません。

・Code quality(コード品質)
・Access to hardware(ハードウェアへのアクセス)
・Adopted code integration Adopted code(採用コード統合)
・Non-compliant adopted code(非準拠の採用コード)

だいたいは上２つになります。採用コードについては、メーカーから指定/許可があったコードを組み込む場合に使えます。社内で開発している汎用ライブラリはだいたい準拠していませんし、採用コードと扱われることもありません。作り直しましょう。
一番苦労するのが、採用コード側の違反により、内製コード側にツールが違反を検出をしたとき。採用コードが悪いのに、採用コードをカバーする形でコード修正をしないといけません。開発が終わったあとに気がつくと大変なことになります。コード解析環境は非常に重要です。
おまたせしました、C言語詳しいおじさんからのつっこみ。
逸脱記録には、逸脱理由分類(4種)以外に、逸脱の必要性、逸脱のリスク、リスクの回避を記載しなさい。
え...？そんなことどこにかいてるんですか。。。。
逸脱記録を作れば逸脱し放題という方針だった場合、地獄を見ることになります。性能のための逸脱というのが逸脱理由分類にあるので、どんな違反もとりあえずこれに分類してしまうのが一番楽です。当プロジェクトは、可能な限り修正する方針で勧めていたため、ギリギリセーフ。プロジェクトによってはここで詰みます。
ただ、いくら最低限にしたとはいえ、コードサイズが大きいプロジェクトだと件数は膨大。結局3人月くらい掛けて追加作成しました。

■最後のつっこみ
前の章で提出書類はすべてのはずでは？
はいの通りです。ここより後は、全部メーカーのわがままです。
お金を出すのはメーカーなので、残念ながら最後までお付き合いします。

QACのワーニングってMISRA C/CERT Cに違反していないものがあるけど、どのような扱いになってますか？

QACというツールは本当にさまざまな警告を出します。なかにはMISRA-C/CERT-Cに関係ないものも大量に含まれます。あきらかに関係ないものはQACのルール設定を変更して表示されないようにしますが、コード解析(人力)に有用な警告もあるため、あえて非表示にせずそのままにしています。

QACにも間違いはあり、MISRA C/CERT Cと関連付けされているが関係ない警告もちらほら。一つずつ丁寧に説明します。

最後に残ったのは、QACの警告を人力で確認し、違反でないと判断した警告。たとえば、

・NULLポインタを算術演算する可能性があります
・無効なポインタを間接参照する可能性があります
・符号無し算術演算において、ラップアラウンドのチェックがありません

いや、QACくんあきらめたらここで試合終......
はい、人力で全部確認しました。メーカーにはコードレビューで実施していますと説明します。
嫌な予感がしますよね。そのとおりです。人力で確認した証拠を出せとのこと。
そんなんあるわけ無いじゃん。

■終わらない資料作成
人海戦術で資料を作成します。ただ、万にも及ぶ警告数のため十数人月の予定外費用の発生。PMは部長に怒られます。なんとか提出し事なきを得ます。
思い出したくもないので、詳細は省略します。

■終わらない資料作成２
では、この車両のソフトは準拠と判断します。
この言葉をきいてホッとしたと同時に一つの疑問が。これ、車両が変わったらもう一回必要？そのとおり、車両ごとにこの作業が必要です。
私の仕事はこれからもまだまだ続きます。

■あとがき
いまから、MISRA C/CERT C準拠のソフト開発を行う後輩諸君。このnoteを３回読んだ上で、メーカーとの工数交渉に挑んでほしい。くれぐれも健康には気をつけて。すでに同じ道を歩んだ先輩様。私のときはこうだったという話をぜひ聞かせてほしい。私の体験はあくまで、１メーカーとの出来事なので、全てのメーカーでこの様になるというわけではない。私の苦労が必要なことだったのか、いまはそれだけを知りたい。

■今後
今後はMISRA C:2012/CERT-Cについての解説を投稿していきたい。
乞うご期待。

[eof]