Updates
皆様にご好評をいただいております、Automotive SPICE ハンドブックをVer.4対応として発行いたしました。これまでのコンセプトは、そのままにAutomotive SPICE 4.0の改訂内容に合わせて刷新しております。ご興味のある方は、弊社までお問合せください。 次のコンセプトで作成しています：・弊社オリジナルの実作業における流れと、プロセス関連図を記載・１プロセス４ページで構成・見開き１ページ目に、目的、成果、情報項目、情報項目特性を集約・見開き２ページ目に、基本プラクティス、実作業の流れ図、プロセス関連図を集約 掲載プロセス SWE.1ソフトウェア要求分析プロセス
Automotive SPICE 4.0に関するコラム、今回はMLE（機械学習）についてお届けいたします。 はじめに機械学習という言葉を耳にした方は多いのではないでしょうか。今回Automotive SPICE 4.0で機械学習が追加されたことで、各社独自に実施していた機械学習プロジェクトのプロセスが明確化されました。機械学習とは、特定のトレーニングデータから傾向（パターン）やルールを見つけ出し、その知識を他の同様のタスクに適用するソフトウエアの機能を指します。この機会学習の発達により、特定の分野では、人を上回る能力を発揮するようになっています。象徴的な事例がAlphaGo（コンピュータ囲碁プログラム）で、人間同士では何百年もかかるような膨大な数の対局経験をバーチャルにこなし、囲碁の世界チャンピオンを破るにまでに至っています。 機械学習プロセスの流れ以下がAutomotive SPICEで定義されている機械学習プロセスになります。これを見てわかる通り、通常のシステム開発プロセスと大きな違いはありません。MLE.１：機械学習要件分析・対象となるシステムや問題領域を理解し、機械学習システムが適用される領域やデータの特性を理解した上で、要件の洗い出しを行う。MLE２：機械学習アーキテクチャ・機械学習システムの全体的な構造やコンポーネントの設計を行います。モデルの選択やデータのフロー、各機能モジュールの役割と相互関係を明確化します。MLE３：機械学習トレーニング・モデルの学習を行います。トレーニングデータを使用してモデルのパラメータを調整し、データのパターンや関係性を学習させますMLE４：機械学習テスト・トレーニング済みモデルの性能や予測の精度を評価するために、テストデータを使用してモデルを評価する。さらに性能改善やバグ修正のための実験や検証も行いますSUP.11：機械学習データ管理・適切なデータの収集、前処理、変換、正規化、データセットの管理など、データに関する一連の作業を実施する。これにはデータの品質管理やセキュリティの確保も含まれています 機械学習の事例各社、機械学習を取り入れ医療や科学、無人配達などへの適用が進められています。今回は車載の自動運転に機械学習を適用している具体例をご説明いたします。■画像解析におけるAI・自動運転車の制御は「認知・判断・制御」に大別されます。・AI（人口知能）は主に「認知」の部分で使用されています。・車両に搭載されたカメラやLiDAR、ミリ波レーダーなどのセンサーが映し出すデータを分析し、物体を認識できるようにAIをトレーニングしています。■学習データの収集・AIのトレーニングには、車両に搭載されたカメラで撮影した画像とその画像にタグ付け（例：人間、犬、猫、信号等）するための情報を含むデータが使用されます。 自動運転では車載カメラやセンサーを使用し物体を認識したうえで、走行、停止、回避（判断）し必要に応じて制御します。 機械学習を導入することによるメリットやデメリット最後に機械学習を採用することによるメリットやデメリットについてコメントしたいと思います。・自動化によるコスト削減・高精度の識別、予測による効率化機械学習を取り入れる最大のメリットは上記に集約されるでしょう。一方で以下のようなデメリットもあります。・自動化、効率化の効果を予測しづらいこれは、「うまくいく」と想定されるテーマにおいても、実際にデータを集めて学習を行ってみるまで、本当に精度の高いモデルが作られるかどうか分からない。仮に「精度の高いモデルが作れたとしても、永続的に使い続けられるわけではない」という点が挙げられます。 今後、注目を浴びることになると思われる機械学習についてコメントいたしました。もし、もっと機械学習について知りたい、などご要望ございましたらコメントお願いいたします。
Automotive SPICE v3.1 ではBP5：双方向のトレーサビリティの確立として ソフトウェア要件とソフトウェアユニット間の双方向のトレーサビリティを確立するという要求が存在していましたが、Automotive SPICE 4.0 では、この記述が削除され ソフトウェア詳細設計とソフトウェア要求との間の一貫性を確保しトレーサビリティを確立するという内容に変更になりました。 Automotive SPICE v4.0 SWE.3 から引用： Automotive SPICE ガイドライン2nd editionには、次のような主旨の説明が記述されています Automotive SPICE v3.1 とは対照的に、詳細設計におけるソフトウェアユニットまたはコードに対しては、ソフトウェア要求とのトレーサビリティを直接的には要求しない 従って、UML/SysMLシーケンス図またはアクティビティ図などの動的モデルを作成し、それを要求に割り当てることは、ソフトウェアコンポーネントおよびソフトウェアユニットへのトレーサビリティを表すことになる また、「ソフトウェアユニット」とは、と題して次のような記述があります 用語「ソフトウェアユニット」は時々、ソースコードにおけるソフトウェアユニットの実装と誤って解釈されることがある。 しかしながら、ソースコードは詳細設計において特定されたソフトウェアユニットの実装ソリューションであるため、この解釈は意図されていない。 そもそも「ソフトウェアユニット」とは、実装レベルの用語ではなく、論理的モデリングレベルの用語である。 論理的モデリングレベルは詳細な詳細設計を表し、詳細なソフトウェア設計は常にソースコードから意味論的に抽象化されたものであるが、ソースコードそのものと同一ではない。 更に、ソフトウェアアーキテクチャ設計及び詳細設計はアプリケーションドメイン言語とエンティティを使用して作成される。 その結果、ソフトウェアユニットは「分離不可能な一貫した振る舞いの一部分」であり、「単独で検証可能なもの」でもあるという見方はそもそもアプリケーションドメイン知識の視点となる。 これまで、ソフトウェア要件とソフトウェアユニットのトレーサビリティとは何を意味するのか悩まれてきた方も多かったと思います。アセスメントで証明するために無理な作業をしていたケースも多々ありそうですね。 参考に、Automotive SPICE 4.0の一貫性とトレーサビリティの図を引用しておきます。 今回の整理では、ソフトウェア要求のトレーサビリティは単純に2つのパターンで考えれば良いことになります。かなりすっきり整理されたのではないでしょうか？ オプションA：ソフトウェアアーキテクチャを経由するトレーサビリティ 要求を実現するために、ソフトウェアコンポーネントおよびソフトウェアユニットの相互作用のもと実現する場合に必要なトレーサビリティ オプションB：直接詳細設計のエレメントにつながるトレーサビリティ CANの信号データなど、要求を動的な振る舞いとして設計する必要がない場合のトレーサビリティ 日吉昭彦
この度、弊社ではロボットプロセス技術部を新設し、2024年4月1日より事業を開始いたしました。近年、DX（デジタルトランスフォーメーション）への対応が活発化している中で、弊社としましても新しい技術への対応を進めていくために、新技術の獲得と展開を進めて行く所存です。ロボットプロセス技術部では、RPA（Robotic Process Automation）による業務効率化を中心に事業展開いたしますが、従来我々が得意としてきた開発プロセスの改善においても新技術を活用いたします。プロセスマイニングを活用することにより、開発プロセスでは困難であったデータオリエンテッドな業務改革の実現を目指します。
Automotive SPICE 4.0が発行され、Automotive SPICE （VDA）ガイドラインも含めて内容を確認していますが、SWE.2 のガイドラインにとても良い説明が書かれていますので、なるべく原文を引用しながら、個人的な見解を書いてみます。 青文字：VDAガイドラインから引用黒文字：筆者のコメント ソフトウェアアーキテクチャ設計の目的Automotive SPICEはそれぞれのレベルでの設計上の決定を通じて、要求が体系的に下位レベルに細分化されるべきであることを強調している。つまり、要求レベルのフワっとした内容を、ソフトウェアで実現するための仕様に落とし、仕様をインプットにして詳細な設計を実施していく段階的なアプローチを前提としているということです。ソフトウェア構造においては、コンポーネント、モジュール、ユニット、関数と構造化設計をしていくことが高品質で変更にも強いソフトウェアを作ることが可能になります。結果的に、生産性も高まってくるわけで、こういった考え方がソフトウェアアーキテクチャ設計の目指すところになります。 その背後にある考え方は以下の通りである： あまりにも多くの情報に圧倒されて間違いを犯さないようにする（「分割統治」の原則） 将来のスタッフにソフトウェアの文書を提供し、潜在的に膨大なソースコードからソフトウェアがどのように作動するかを非効率的に学習する必要がないようにする 暗黙の知識が文書及び最終製品において失われていないことを確実にする それぞれのレベルでの要求が完全にカバーされていることを確保する 最終的に、余分なソフトウェアエレメントが存在しない（つまり、SWは要求が必要とする以上のものを含まない）小規模ソフトウェアの場合、要件毎に必要な関数を作り関数と関数をつなげた方が手っ取り早く機能を実現できるため、構造化設計の必要性を肌で感じていない方も多いのだと思っています。開発規模の増大化や実現機能の複雑化に加え、再利用性が事業上の重要課題になってくると、そのパラダイムを変える必要が出てくるはずです。事業に貢献するためのソフトウェアアーキテクチャを作りあげること。アーキテクチャに基づいて、それぞれの領域の専門家が分業していくことで、品質はもとよりTime to Marcketに貢献できるソフトウェア開発と保守が可能になるのです。 ソフトウェアアーキテクチャ設計静的及び動的なビューを超えて、どのようなビューが必要であるかについての共通的な定義はなく、ビューがいくつあれば完全であるかに関する基準はない。ビューの数及び種類は製品のサイズ並びに複雑性に大きく依存する。 業界には、綿密なアーキテクチャ設計記述のために、ビューに必要となる情報の種類（ある種類のビューを構築するためのパターン、テンプレート、規約の集合体である「ビューポイント」）、及び複数のビューの統合について特定したアプローチがいくつか存在する。多くの場合、ソフトウェアアーキテクチャ設計はテキストの説明によって補足されるソフトウェアのグラフィック的な表現である。ここにも書かれているように、アーキテクチャ設計はグラフィック系のソフトウェアを使用して作成することが一般的です。過去には、VISIOなどのDraw系ソフトウェアを使われている方が多かったようですが、現在ではSysML系のソフトウェアなどを使われているケースも多くなっています。更には、テキストから図表を自動作成してくれるSphinxの活用も一般的になってきているようです。動的なビューとしては、つぎのような例が一般的でしょう： シーケンス図（ソフトウェアコンポーネント間の相互作用を記述） 状態遷移図（製品を制御するために必要な動作状態と状態を遷移するイベントを記述） アクティビティ図（処理実行の流れと条件分岐を記述） データフロー図（データの流れを記述）開発するソフトウェアにとって、最適なビューを使うことがポイントとなります。動的ビューの事例は、弊社発行のAutomotive SPICE入門書籍でも掲載していますので参考にしてみてください。https://www.bgarage.co.jp/news/323/ 静的なソフトウェアアーキテクチャのビューは、ソフトウェアを高い凝集性及び低い結合性をもつ管理可能なエレメントに分解することを可能にする。この分解は、これらのアーキテクチャエレメントへの要求の割り当てを支援し、開発者への作業パッケージの配布を整理するのに役立つ。 アセスメントの範囲外で開発されたソフトウェアのアーキテクチャエレメント（例えば、オープンソースソフトウェア、プラットフォームソフトウェア、第三者ソフトウェア）も、ソフトウェアアーキテクチャ設計の専用エレメントとして含まれ、同様にインタフェース分析、動的な振る舞い、リソース消費目標などに対しても考慮されなければならない。 必要に応じて、アーキテクチャエレメントはアーキテクチャ設計において最下位レベルのエレメントであるコンポーネントに至るまで更に具体化される。コンポーネントは１つ以上のユニットで構成され、ソフトウェア詳細設計（SWE.3）の対象となる。静的ビューについては、疎結合な設計をするために互換性や拡張性の観点からみて最適な構造を作ることを支援します。要求全体を見ながら、共通的な機能をまとめたり個別機能間とのインタフェースなどを考慮しながら、ソフトウェアコンポーネントを配置していくことになります。このような構造設計を実施すると、要求とソフトウェアが1対1にならないため、分割された各ソフトウェア要素にソフトウェア要求を割り付けることや、要求に対してソフトウェアコンポーネント間の相互動作を文書化して要求の網羅性を検証する必要が出てきます。そもそも構造化ができていない、関数の連結によるアーキテクチャであれば、要求の割り当てやトレーサビリティもあまり意味を持たないものになります。疎結合が高い設計は、分業化が進むことにより生産性や品質へ寄与しますが、反面ソフトウェアの全体を見渡せる人材が少なくなり、問題解析が１人では困難になるという副作用もでてきます。ソフトウェア構造の例は、コラム（ソフトウェアドキュメント間のトレーサビリティ）をご参照ください。https://www.bgarage.co.jp/news/190/ 割り込みに関して最先端技術によれば、割り込みサービスルーチンはドメインロジックの振る舞い又は複雑なアルゴリズムを含めてはならないが、割り込み処理は依然として並列制御又はデータフローさえも表示している。特に、高い割り込み負荷はアプリケーションにおいて干渉を引き起こす可能性がある。 そのため、Automotive SPICE v4.0 では、それらをソフトウェア設計、特に動的な設計に反映させるためにソフトウェアユニットとして関連する割り込み処理を扱うことが重要であると考えている。割り込みについては、リアルタイムOSで見られるような割り込みクラスを定義して、タスクをダイナミックに制御することができていないことが多いようです。スケジューラに頼りすぎた設計になり、思わぬ障害につながるケースも数多く見てきました。ソフトウェアのアーキテクチャ設計では、割り込み処理に加えて、タスク制御やリソースおよび性能面も含めたソフトウェアの基本となるメカニズムの可視化も大切になります。 日吉昭彦
Automotive SPICE 4.0 に関するコラム、今回は「戦略」BPについてお届けいたします。 はじめにこれまでのAutomotive SPICE v3.1では例えば「SUP.8.BP1：構成管理戦略の策定」の様に、特にSUPプロセス群において、そのプロセスの戦略を策定することをBPで求めていました。また、その際の作業成果物特性として「08-04 構成管理計画書」の様なプロセス活動の計画書が定義されていました。そのため、「構成管理計画書」や「構成管理戦略」といった名前の文書を作らないとSUP.8.BP1は満足できないのでは？と考えて来た方も多かったと思います。でも、A-SPICEの能力レベル1は「実施されたプロセス」なので、本来は計画が無くてもそのBPの内容が実施されていればOKのはず。プロセスの実行計画は能力レベル２で出てくるじゃない。なんでレベル1で計画書が必要なの？といった疑問も出てきますよね。 A-SPICE 3.1の誤解とガイドラインの主張Automotive SPICE v3.1のガイドラインでは、「SUPプロセスはレベル1において、すべてのプロセスを横断するため高い度合の形式化を必要とする。でもレベル2を達成するにはレベル1の戦略を超えて達成することがまだ多くある。戦略は「戦略」と名の付く文書を必要とはしない」とあります。この考えはSUPプロセスに限らずSWE.4/SWE.5/SWE.6/SYS.4/SYS.5のテストプロセスでも同様で、テストを行うためのテスト戦略がBPで定義されていました。 つまり、BPの活動を効果的に実施してもらうためには場当たり的にやるのではなく、最初にプロジェクトとしてどうやるかを考えてからやってね、という意味合いで「戦略」が必要と定義したのですが、結果的にはBPに書いてあるから「戦略」や「計画書」が無くちゃいけない、に捉えられてしまい、アセスメントでも例えば構成管理活動がキチンと行われているにも関わらず、ただ一点、「構成管理計画書」が無いという理由でレベル1に課題があるといった評価になってしまう様な事態が発生していました。 A-SPICE 4.0では戦略が不要か？Automotive SPICE 4.0では、そんな「戦略」BPが引き起こしていた混乱や誤解を避けるために、「戦略」と名の付くBPが全て無くなりました。また、併せてこれまで「戦略」BPのあったプロセスで定義されていた「08-04 構成管理計画書」の様なプロセス活動の計画書の定義も削除となりました。これで、レベル1はあくまでBPの活動がちゃんと出来ているかに焦点が当たる様になり、アセスメントでも構成管理計画書が無いからダメといった、本来の意図では無い評価を防ぐことになります。 でも、BPの活動を効果的に実施するには、プロジェクトのメンバーが各自で好きな様に実施するより、プロジェクトとして最初にどうやるかをキチンと考えて、プロジェクトの皆でそのやり方を守って実施した方が良い結果に繋がりますよね。なので「戦略」BPは無くなりましたが、最初にちゃんと考えることが大切！って部分は変わらないのだと思います。 さいごに今回のコラムはいかがでしたでしょうか？今後も数回にわたってAutomotive SPICE 4.0に関するコラムをお届けいたしますので、ご期待ください。（安部宏典）
今回はAutomotive SPICEの要求事項を満足するためのヒントとして、顧客要求の取り扱いについて説明いたします。特に自動車開発の場合、顧客の要求仕様に書かれている内容が、明らかにシステム要求レベルのものではなく、ソフトウェア要求（SWE.1）やハードウェア要求（HWE.1）レベルになっている場合や、設計上の制約（SWE.3：設計レベルの記述）となるレベルまで踏み込んで書かれているケースが多く見受けられます。このような詳細なレベルの要求の取り扱いに悩んでいませんか？ 具体的な悩みとしては： 詳細な顧客要求を、システム要求仕様書（SYS.2）に、どのように落とし込めば良いのか？ システム要求仕様書にソフトウェア要求やソフトウェア設計上の制約に相当するのものを記載した場合、ソフトウェア要求や設計書には、どのように記述すれば良いのか？（同じ文書を複数の文書にコピーするのか？） 顧客要求からシステム要求、ソフトウェア要求へのトレーサビリティは、どのように取るのか？ 顧客要求が設計上の自由度が無いような詳細レベルの場合、システム要求仕様書にソフトウェア要求レベルや設計制約レベルの顧客要求を記述する必要はありません。顧客要求から、（システム要求をスキップして）ダイレクトにソフトウェア要求に組み込む、あるいは設計へのトレーサビリティを取れば良いのです。全ての顧客要求をシステム要求に組み込み、さらに同じ内容を後続の要求（例：ソフトウェア要求）にコピーするような無駄な作業をする必要はないのです。 ただし、１つだけ注意点があります。このように、システム要求をスキップして詳細レベルの書類に落とし込む場合、その要求や制約が、皆さんが開発するシステム要求やアーキテクチャレベルに影響がないことを評価した上で、判断することが重要です。詳細レベルの要求や設計制約と思える要求は、顧客の立場から主張する必要があるものであり、皆さんのシステム設計にはフィットしない場合もあるからです。その場合は、顧客と相談の上、詳細レベルの要求や設計制約を変更してもらう必要があります。 このような困りごとが多いことは、VDAも認識しているようで Automotive SPICE ガイドライン 改訂第２版のSYS.1に説明が記載されていますので参考にしてください。 Automotive SPICEを使っていると、「この作業無駄だなぁ」とか「非効率だ！」と思いながらも、Automotive SPICEの認証を受けるためには、仕方なく実施しているケースを数多く見ます。もし、「無駄」だと思った場合、あなたの感覚は正しく、それは無駄な作業なのだと思います。もう1歩踏み込んでAutomotive SPICEで記載している事項の本質的を考えてみることをお勧めします。きっと違う実装方法があるはずです。 とは言え、なかなか判断が難しいですよね。そのような時は、弊社までお問合せください。微力ながら皆様のお力になれることを願っています。 日吉昭彦
Automotive SPICE 4.0 に関するコラムの第３弾は、システム領域の適用範囲についてお届けいたします。 そもそもシステムとは？一言に「システム」といっても、人によってその定義や解釈は様々です。Automotive SPICEでは、システムを以下のように定義していました。※１ 特定の環境内において、特定の機能または一連の機能を実現するために編成された相互作用のあるアイテムの集合。さらに、この相互作用のある「アイテム」を、Automotive SPICEでは、「識別可能なシステムの一部」とし、ハードウェアやソフトウェア、下位のシステムといった構成要素と位置付けていました。つまり、ハードウェアとソフトウェアを組み合わせたものをシステムとしています。しかし、この定義に準ずると、自動車もシステムであり、自動車を構成する駆動システムやECU、範囲を広がると車車間通信の仕組みも「システム」として解釈することができます。この解釈自体に間違いはありません。それでは、Automotive SPICEのシステムエンジニアリングプロセス（SYSプロセス）は、どんな製品を対象に、どのように適用すれば良いでしょうか？ SYSプロセスの適用範囲Automotive SPICEは、様々な製品に対してアセスメントできるように考えられたプロセスモデルですので、製品の階層構造を表現したものにはなっていません。これは、ガイドラインでも明確に記述されています。しかし一方で、ガイドラインでは、「製品の階層構造の各レベルでシステムエンジニアリングプロセスを適用することができる」とも記述されています。少し具体的な例が掲載されているのでご紹介します。階層的なシステム開発の例： メカトロニクスシステムや駆動システムは、メカトロニクス製品であり、メカトロニクス製品を開発するサプライヤには、SYSプロセスが適用可能である ECUは制御デバイスであり、一般的にハードウェア、ソフトウェア、ケース、コネクタ等で構成されるため、ECUを開発するサプライヤには、SYSプロセスが適用可能である 完全に組み立てられたPCBを開発するサプライヤには、HWEプロセスを適用するべきである 半導体開発の例： マイコンやSoC等の半導体は、一般的にハードウェア、機械的な筐体、ファームウェア等で構成されるため、サプライヤには、SYSプロセスが適用可能である さいごにいかがでしょうか？これらからもわかるように、ECUの開発だけでなく、複数のECUやセンサー、アクチュエータで構成される上位システムに対しても、SYSプロセスが適用可能であること、さらには、ECUの構成部品である半導体を開発する際にも、SYSプロセスが適用できることがわかると思います。皆さんが開発する製品の階層構造に合わせて、多段的にSYSプロセスを適用することを検討してみてください。内山哲三 ※１：Automotive SPICE 3.1における定義です。Automotive SPICE 4.0で明示的な定義がなくなりました。また国際標準である、ISO/IEC 26702 IEEE Std 1220-2005では、製品（ハードウェア＋ソフトウェア）だけでなく、製品と使用する人や、使用する際に利用する設備や機材、手順もシステムの一部としていますが、今回はAutomotive SPICEでの定義を活用して、わかりやすく解説しています。