ビジネスガレージ株式会社

ソフトウェアエレメント、ソフトウェアコンポーネント、ソフトウエアユニットの関係について

Automotive SPICE v4.0ではソフトウェアに関して以下の３つの用語を用いていますが、それらの関係について、ソフトウェア設計工程（SWE.2、SWE.3）での取り扱いについて解説します。ソフトウェアエレメントソフトウェアコンポーネント及びソフトウェアユニットを総称して、ソフトウェアエレメントと定義します。ソフトウェアコンポーネントソフトウェアアーキテクチャで記述するソフトウェアエレメントをソフトウェアコンポーネントと定義します。ソフトウェアエレメントは、ソフトウェアユニットの上位に位置し、ソフトウェアアーキテクチャ設計（SWE.2）では、最下位のソフトウェアコンポーネントになるまで、ソフトウェアを適切な階層レベルで分割します。ソフトウエアユニットソフトウェアコンポーネントの一部であり、これ以上細分化されないことが決定された、コンセプトモデルにおける最下位レベルのソフトウェアエレメントを表現したものと定義します。ソフトウェア、ソフトウェアコンポーネント、ソフトウェアユニットの関係を解り易く図で示します。ソフトウェアコンポーネントとソフトウエアユニットの扱いに関しては、Automotive SPICE v3.1 では直感的/十分に記載されていませんでしたが、Automotive SPICE v4.0 では、 SWE.2 （ソフトウェアアーキテクチャ設計）ではソフトウェアコンポーネントの振舞いを定義する SWE.3 （ソフトウェア詳細設計およびユニット構築）ではソフトウェアユニットの振舞いを定義すると明記されました。 SWE.2 で定義した各々のソフトウェアコンポーネントは、SWE.3 で複数のソフトウエアユニットによって構成されます。Automotive SPICE VDA ガイドライン第２版を参照し、SWE.2プロセス、SWE.3プロセスを通してソフトウェアコンポーネント、ソフトウェアユニットの関係を整理しました。＜SWE.2プロセスでの作業概要＞ソフトウェアアーキテクチャ設計を実施する際、ソフトウェアの静的側面として、ソフトウェアを個々の機能に着目してソフトウェアコンポーネントに分割し、ソフトウェアコンポーネント毎の機能を（ブラックボックスとして）定義します（ソフトウェアコンポーネント設計）。大規模なソフトウェアコンポーネントでは、そのコンポーネントを複数のコンポーネントに分割するケースもあります（コンポーネントの多重構造）ソフトウェアコンポーネント内部が、これ以上分割できないソフトウェアユニットに分割されるまで、ソフトウェアコンポーネントのブレークダウンを繰り返します。ソフトウェアの動的側面として、個々のソフトウェアコンポーネントの動作概要、及びソフトウェアコンポーネント間インタフェースを定義します。＜SWE.3 プロセスでの作業概要＞ SWE.2で作成したソフトウェアアーキテクチャ設計に基づいて、ソフトウェアコンポーネントを詳細にブレークダウン設計します。ソフトウェアユニット毎の機能を（ブラックボックスとして）定義します。ソフトウェアの動的側面として、個々のソフトウェアユニットの詳細な動作、及びソフトウェアユニット間インタフェースを定義します。最後に、ソフトウェア詳細設計に基づいて、ソフトウェアユニットのソースコードを作成します。実際の開発現場ではソフトウエアを様々な用語（例：ファンクションブロック、モジュール、セクション、ユニット、関数etc.）を用いて管理されていると思いますが、Automotive SPICE v4.0 で使用する３つの用語（エレメント、コンポーネント。ユニット）との対応を明確にすることで、Automotive SPICE への対応が効率的に実施できます。ご不明な点等あれば、弊社までお問合せください。海農公宏

AIの力でリアルを超える！多言語対応の次世代動画制作を始めました

こんにちは、ビジネスガレージマーケティング担当です。この度、最先端のAI技術を活用した革新的な動画制作サービスを開始しました！このサービスでは、任意のメンバーをAIアバターとして作成し、まるでその人が実際に話しているかのようなリアルな動画を作ることができます。 AI技術はその人の声も忠実に再現し、視聴者に違和感のない体験を提供するとともに、視聴者の集中力と理解度を向上させます。さらに驚きなのは、以下の動画48秒~にあるように、AIアバターに英語を話させたりと、どんな言語にも対応することができることです。 ※画像をクリックすると動画を再生することができます。現段階ではアクセントや細かいニュアンスに一部改善の余地があり検証を進めておりますが、それでも、このサービスを活用することで動画を高品質に制作できるだけでなく、動画制作におけるコストと時間を大幅に削減することができ、例えば企業のトレーニング動画等に使用することで教育効果を大幅に向上させることができるものと確信しています。またトレーニング動画のサンプルとして日本語版と英語版の動画を作成しました。以下をご覧ください。トレーニングサンプル動画はこちら！この動画を通じて、最先端のAI技術の魅力を体感してください。詳細については、ホームページのお問い合わせフォームからお気軽にご連絡ください。

「テスト」から「検証」へ　－　Automotive SPICE 4.0の「検証」プロセス　－

Automotive SPICE 4.0 に関するコラム、今回は「検証」プロセスについてお届けいたします。はじめにこれまでのAutomotive SPICE v3.1にあった「テスト」と名の付くプロセスは、v4.0では以下の様に「テスト」の代わりに「検証」という用語に変わりました。SWE.5：ソフトウェア統合および統合テスト→ソフトウェアコンポーネント検証および統合検証SWE.6：ソフトウェア適格性確認テスト→ソフトウェア検証SYS.4：システム統合および統合テスト→システム統合および統合検証SYS.5：システム適格性確認テスト→システム検証なぜ「テスト」から「検証」に変わったか Automotive SPICE v4.0のガイドラインでは、「特に、システム及びハードウェアのレベルでは、テストだけが唯一の検証アプローチではなく、測定、計算または物理的なサンプルを使用するシュミレーションなどは他の検証方法である」とあります。より包括的な「検証」という用語を用いることにより、テストに限定しないで最も適した検証手段を選んで下さいというメッセージになりました。もともとv3.1でも、SWE.4「ソフトウェアユニット検証」プロセスだけは、ユニット検証手法としてテストだけでなく静的解析やコードレビューもあることから、「ソフトウェアユニットテスト」ではなく「ソフトウェアユニット検証」というプロセス名になっていました。V4.0ではこの考え方が全テストプロセスに広がったことになります。これまでのテストプロセスとの違い用語の変更に伴い検証プロセスのBP（基本プラクティス）の内容も変わりました。v3.1 SWE.6：ソフトウェア適格性確認テストとv4.0 SWE.6：ソフトウェア検証を比較すると以下となります。 Ver3.1のSWE.6.BP1「回帰テスト戦略を含むソフトウェア適格性確認テスト戦略の策定」はV4.0では「戦略」がBPから無くなるために削除となり、「テスト仕様の作成(BP2)」は「検証手段の仕様化」、「テストケースの選択(BP3)」は「検証手段の選定」に、「ソフトウェアのテスト(BP4)」は「ソフトウェアの検証」と、その表現を変えています。これまでは「テスト仕様の作成」というBP名称だったため、とにかく「テストしなければならない」という思いが強かったのではないかと思います。そのため本来机上検証の方が効果的かつ効率的な項目においても、無理してテストを行うような場面があったのではないでしょうか。でもVer4.0では「この項目はテストで検証」「この項目は机上で計算」と戦略的に検証手段を選択することを求めていますので、テストに拘らずより検証目的に適った検証手段を選択することとなり、結果的に検証品質が向上し、製品の品質向上に繋がると考えます。（安部宏典）

Automotive SPICE 4.0 SWE.5 ソフトウェア統合テストの考え方

Automotive SPICE 4.0では、各プロセスの目的は変わっていないとしならがら、細かい点で修正が盛り込まれています。Automotive SPICEのアセスメントを予定している方には、目的は変わらないと言われても、不安に思われている方も多いと思われます。今回は、SWE.5 ソフトウェア統合テストに関する変更点についてお伝えします。ソフトウェア統合および統合テストについては、インタビューの場面でもアセッサと論点がかみ合わず、対応に苦慮された経験をお持ちの方も多いのではないでしょうか？よくあるケースとして：いわゆるビックバン：全てのソフトウェアをビルドして統合するので段階的な統合やテストは実施していない（する必要性を感じていない）統合テストとは、ビルドしたソフトウェアを使って、機能を確認するテストであるという説明になり、質疑に時間がかかってしまうケースが多いように見受けられます。勿論、製品開発の形態（新規、派生など）や、プロジェクトの状況などにより、統合やテストの方法は変わってきます。しかしながら、Automotive SPICEにおける考え方を理解しておくことで、状況に応じた説明をすることが重要だと思います。そこで、VDAガイドライン第２版をみながら統合テストのありかたを整理してみました。ソフトウェア統合および統合テスト（検証）の考え方は次の通りです： ❶コンポーネント内のソフトウェアユニット相互が設計通りに振舞うことを検証する❷コンポーネントが設計通りに正しく動作することを検証する➌コンポーネント相互が設計通りに振舞うことを検証する VDAガイドラインでは、次の絵を使って解説しています。下記の４点は、Automotive SPICE v3.1では直感的/十分には記載されていなかったとして、Automotive SPICE 4.0 では各プロセスに明確に定義されました。 SWE.2 単体のソフトウェアコンポーネントの振舞いの定義（コンポーネント間の相互作用とは対照的なものとして） SWE.3 単体のソフトウェアユニットの振舞いの定義 SWE.5 ソフトウェアユニットをそれらのコンポーネントに統合および統合検証 SWE.5 単体のソフトウェアコンポーネントの検証（他のコンポーネントとの統合に先立ち）これらを別の形で図示すると2023.10.7発行のコラム（ソフトウェアドキュメント間のトレーサビリティ）の中で「統合テスト」のアイコンで示したことと、ほぼ同じことを言っていることがわかります。当たり前といえば、当たり前のことなのですが、アセスメントモデルのプラクティスとして記載されてしまうと、求められていることがわかりにくくなってしまうのかもしれません。このように図で表現するとわかりやすいのではないでしょうか？ご不明な点等あれば、弊社までお問合せください。日吉昭彦

Automotive SPICE プロビジョナルアセッサー資格更新にアセスメント経験は不要になりました

intacs®︎はこれまで、Automotive SPICE v4.0への更新に伴い、「今後はプロビジョナルアセッサー更新時に最低１つのType EE – AT（ = Assessment Team member Experience Evidence）が必要」（コ・アセッサーとして50時間以上のアセスメント経験が必要）とアナウンスしてきましたが、このルールの撤廃が決定されました。このルールを今すぐ適用すると、資格維持できない人が出てくるという懸念をVDAが示したために暫定的に廃止されたとのことです。既に現在intacs®より提供されているAutomotive SPICE®4.0 Upgrade Training 教材 Module 2: Certification Rulesの中でPROVISIONAL ASSESSOR に対するLICENSE RENEWALが(no requirements)と記されています。これにより、プロビジョナルアセッサー資格者は、従来通り3年毎にVDAに資格更新費用を払い込めば、資格の維持が可能となります。ただし暫定処置ということであり、今後また「資格維持にType EE – ATが必要」とのルールが復活する可能性はありますので、プロビジョナルアセッサーの方はコ・アセッサーの機会を考慮しておくことをお薦めします。

Automotive SPICE SYS（システムエンジニアリング）プロセス担当について

製品開発体制の中でSYSプロセス担当が不在になりがち一般的な製品開発組織は下記の様な体制が多い様です。しかし、このような開発体制の場合、システムエンジニアリング（SYSプロセス）はどこが担当するのが良いのでしょう？・プロジェクト全体を纏める「製品開発取り纏め部門」は、SYSプロセスを担当できる技術的なスキルが足りない・「制御／システム開発」は名前は近いが、役割は回路設計(E/E)や制御仕様が担当で、メカやソフトウェアも含めた製品全体の責任は取れない・製品全体のシステム要件整理を纏める担当が明確ではない。しかし、各部門間でそれぞれ要件調整を実施し、その結果を各担当部分の要件としているため特に必要性を感じていない上記のような理由から、SYSプロセスを担当する部門/開発チームが不在になっていないでしょうか。 SYSプロセス担当が不在なことによる弊害・各部門間で調整した要件が、システム要件として纏まっていないため、部門間の議論で気が付かない不整合が開発後半で発生してしまう可能性がある・システム全体の把握した設計ドキュメントが作られず、新規機能を検討する場合に、最適な機能分担がスムーズに行えない（行える人が不在）・システム全体目線でのシステム要件分析やシステムアーキテクチャ検討結果が作成されない。そのため、システム全体検証の項目に抜け漏れが発生して、機能不良や不具合が流出してしまう可能性がある仮想的なシステムチームSYSプロセスは製品品質を向上させるために重要な役割を持っています。組織体制上、どこかの部門・チームがシステム全体を見るSYSプロセス担当となるのは難しいかも知れません。その場合は、例えばこの図の様に、各部門からリソースを出し合い仮想的なシステムチームを構成し、役割と責任を与えて、システム全体を明確にするためのSYSプロセスを適用できるような体制と責任分担が重要となります。さいごに今回のコラムはいかがでしたでしょうか？思い当たることがありませんでしたか？製品開発体制の中に、システム担当部署がいない場合の解決案をご説明しました。仮想的なチーム運営は難しいかもしれませんが、参考にしていただけると幸いです。鈴木功

Automotive SPICE4.0 ハンドブック（第1版）発行

皆様にご好評をいただいております、Automotive SPICE ハンドブックをVer.4対応として発行いたしました。これまでのコンセプトは、そのままにAutomotive SPICE 4.0の改訂内容に合わせて刷新しております。ご興味のある方は、弊社までお問合せください。次のコンセプトで作成しています：・弊社オリジナルの実作業における流れと、プロセス関連図を記載・１プロセス４ページで構成・見開き１ページ目に、目的、成果、情報項目、情報項目特性を集約・見開き２ページ目に、基本プラクティス、実作業の流れ図、プロセス関連図を集約掲載プロセス SWE.1ソフトウェア要求分析プロセス

コラム

2024/05/07

Automotive SPICE 4.0にMLE（機械学習）が追加

Automotive SPICE 4.0に関するコラム、今回はMLE（機械学習）についてお届けいたします。はじめに機械学習という言葉を耳にした方は多いのではないでしょうか。今回Automotive SPICE 4.0で機械学習が追加されたことで、各社独自に実施していた機械学習プロジェクトのプロセスが明確化されました。機械学習とは、特定のトレーニングデータから傾向（パターン）やルールを見つけ出し、その知識を他の同様のタスクに適用するソフトウエアの機能を指します。この機会学習の発達により、特定の分野では、人を上回る能力を発揮するようになっています。象徴的な事例がAlphaGo（コンピュータ囲碁プログラム）で、人間同士では何百年もかかるような膨大な数の対局経験をバーチャルにこなし、囲碁の世界チャンピオンを破るにまでに至っています。機械学習プロセスの流れ以下がAutomotive SPICEで定義されている機械学習プロセスになります。これを見てわかる通り、通常のシステム開発プロセスと大きな違いはありません。MLE.１：機械学習要件分析・対象となるシステムや問題領域を理解し、機械学習システムが適用される領域やデータの特性を理解した上で、要件の洗い出しを行う。MLE２：機械学習アーキテクチャ・機械学習システムの全体的な構造やコンポーネントの設計を行います。モデルの選択やデータのフロー、各機能モジュールの役割と相互関係を明確化します。MLE３：機械学習トレーニング・モデルの学習を行います。トレーニングデータを使用してモデルのパラメータを調整し、データのパターンや関係性を学習させますMLE４：機械学習テスト・トレーニング済みモデルの性能や予測の精度を評価するために、テストデータを使用してモデルを評価する。さらに性能改善やバグ修正のための実験や検証も行いますSUP.11：機械学習データ管理・適切なデータの収集、前処理、変換、正規化、データセットの管理など、データに関する一連の作業を実施する。これにはデータの品質管理やセキュリティの確保も含まれています機械学習の事例各社、機械学習を取り入れ医療や科学、無人配達などへの適用が進められています。今回は車載の自動運転に機械学習を適用している具体例をご説明いたします。■画像解析におけるAI・自動運転車の制御は「認知・判断・制御」に大別されます。・AI（人口知能）は主に「認知」の部分で使用されています。・車両に搭載されたカメラやLiDAR、ミリ波レーダーなどのセンサーが映し出すデータを分析し、物体を認識できるようにAIをトレーニングしています。■学習データの収集・AIのトレーニングには、車両に搭載されたカメラで撮影した画像とその画像にタグ付け（例：人間、犬、猫、信号等）するための情報を含むデータが使用されます。自動運転では車載カメラやセンサーを使用し物体を認識したうえで、走行、停止、回避（判断）し必要に応じて制御します。機械学習を導入することによるメリットやデメリット最後に機械学習を採用することによるメリットやデメリットについてコメントしたいと思います。・自動化によるコスト削減・高精度の識別、予測による効率化機械学習を取り入れる最大のメリットは上記に集約されるでしょう。一方で以下のようなデメリットもあります。・自動化、効率化の効果を予測しづらいこれは、「うまくいく」と想定されるテーマにおいても、実際にデータを集めて学習を行ってみるまで、本当に精度の高いモデルが作られるかどうか分からない。仮に「精度の高いモデルが作れたとしても、永続的に使い続けられるわけではない」という点が挙げられます。今後、注目を浴びることになると思われる機械学習についてコメントいたしました。もし、もっと機械学習について知りたい、などご要望ございましたらコメントお願いいたします。

新着情報