著者 | Zhang Xuhai
スマートカーの急速な発展に伴い、スマートコックピットはパフォーマンスと信頼性の点でいくつかの問題を抱えており、その結果、ユーザーエクスペリエンスが低下し、苦情が発生しています。 。 増加。この記事では、エンジニアリングの観点からスマート コックピット ソフトウェア評価フレームワークを構築することの重要性と、パフォーマンスと信頼性を継続的に向上させる方法について簡単に説明します。
リリースされた「2023 スマート コックピット ホワイト ペーパー - フォーカス」によるKPMG「下半期の電動化」によると、中国の自動車用スマートコックピット市場は拡大を続けており、2022年から2026年までの年平均成長率は17%を超えると予想されており、この分野が大きな発展の可能性を秘めていることが示されている。市場が成長するにつれて、スマートコックピットソフトウェアの機能はより多様かつ強力になり、全体的なインテリジェンスレベルも大幅に向上します。これは、自動車業界がよりインテリジェントでコネクテッドな方向に向かって進んでおり、よりインテリジェントで便利、快適な運転体験を消費者に提供していることを示しています。
(出典:「2023 スマートコックピット白書 - 電動化後半に焦点を当てる」)
市場規模予測が拡大し続ける中、消費者はスマートコックピットソフトウェアへの関心はますます高まっており、苦情の割合も年々増加しています。主にスマート コックピット ソフトウェアの操作エクスペリエンス、パフォーマンス、信頼性に焦点を当て、スマート機能の継続的な増加によってもたらされる課題に焦点を当てています。
自動車品質ネットワークの2023年4四半期の自動車苦情分析レポートによると、スマートコックピット(車両機械)に関連する品質問題がかなりの割合を占めており、その中には第1四半期の苦情欠陥上位20件が含まれています。 ~Q4は自動車機械関連関連部品(オーディオおよびビデオシステムの故障、ナビゲーションの問題、車内相互接続の故障、安全運転支援システムの故障など)が全体の15.89%、10.99%、10.56%、9.56%を占めたそれぞれ苦情。
_(出典: Chezhi.com)_具体的な苦情フォームをさらに確認すると、クラッシュ、黒い画面、フリーズ、応答の遅さなどの問題が非常に深刻であることがわかります。ユーザーの運転経験もまた、ブランドに対するユーザーの信頼と認識を低下させます。
スマート コックピット ソフトウェアの開発傾向とユーザーの苦情を総合すると、操作の容易さに加えて、パフォーマンスと信頼性がユーザー エクスペリエンスに影響を与える最も重要な要素であることがわかります。これら 2 つの重要な要素は、ユーザーの満足度に直接関係しているだけでなく、市場におけるスマート コックピット ソフトウェアの競争力を大きく左右します。
次の記事では、ソフトウェア開発のベスト プラクティスとスマート コックピット分野のソフトウェアの特性を組み合わせて、そのパフォーマンスと信頼性を評価および改善する方法を検討します。
#スマートコックピットソフトウェアシステム自体は一種のソフトウェアであり、その研究開発プロセスもソフトウェアアーキテクチャの設計、開発実装、品質検証の一般的なプロセスに従います。したがって、改善方法を議論する前に、まず次の点を明確にする必要があります。ソフトウェア システムのパフォーマンスと信頼性を正しく評価するにはどうすればよいでしょうか。 1. ソフトウェア アーキテクチャの特性モデル Mark Richards と Neal Ford はかつて、「ソフトウェア アーキテクチャ: アーキテクチャのパターン、特性、実践に関するガイド」の中で「アーキテクチャの特性」について説明しました。 " :測定できない場合、改善することはできません。
アーキテクトは他のユーザーと協力してドメイン要件やビジネス要件を特定することがありますが、アーキテクトの主な責任は、ソフトウェアに必要なドメインに依存しないもの、つまりアーキテクチャ上の機能を定義、発見、分析することです。 。アーキテクチャ特性とは、監査可能性、パフォーマンス、セキュリティ、スケーラビリティ、信頼性、性別など、ドメイン要件やビジネス要件から独立したソフトウェアを設計するときにアーキテクトが考慮する必要があるソフトウェア特性です。多くの場合、非機能要件 (非機能要件) または品質属性 (品質属性) とも呼ばれます。
明らかに、ソフトウェア アーキテクチャの主要な機能は、アーキテクチャ設計の開始時に考慮する必要があり、ソフトウェア開発プロセス中も継続的に注意を払う必要があります。では、ソフトウェア システムを開発する際に考慮する必要がある主要なアーキテクチャ上の特徴は何でしょうか?
ISO/IEC 25010:2011 は、国際標準化機構によって推進されている一連の規格です (現在 2023 年バージョンに更新されています)。ISO システムおよびソフトウェアの品質要件および評価 (SQuaRE) システムに属しています。そして、グループのシステムとソフトウェアの品質モデルを定義します。この品質モデルは、ソフトウェアの品質を説明および評価するために広く使用されており、ソフトウェアの主要なアーキテクチャ上の特徴をモデル化する際に役立ちます。
ISO 25010 で説明されている品質モデルは次のとおりです (図ではパフォーマンスと信頼性に関連する部分が強調表示されています):
## ソフトウェア アーキテクチャに関する ISO 25010特性(規格の原文では「品質属性」と呼ばれる)は分割されており、機能性、信頼性、パフォーマンス効率、保守性、移植性などの多くの側面をカバーしています。各アーキテクチャ機能は、それに関連する重要な側面を定義しており、機能の特定の次元をより詳細に説明する複数のサブ機能も含まれています。この品質モデルは、ソフトウェアの品質をよりよく理解し、評価するための包括的かつ一般的なフレームワークを提供することがわかります。 パフォーマンス特性の場合、モデルは時間特性、リソース使用率、容量の 3 つのサブ特性に分割され、信頼性特性の場合、モデルは成熟度、可用性、耐障害性、容易性の 4 つのサブ特性に分割されます。回復セックス。 もちろん、どのようなソフトウェアにもそれぞれの特徴や動作環境があり、上記モデルのアーキテクチャ上の特徴をすべて満たすソフトウェアは優れていますが、社内向けと同様にコストが高くつくのは避けられません。ユーザーが 3 人だけのシステム 可用性に合わせて柔軟に拡張できるようにシステムを設計する必要はありません。スマート コックピット ソフトウェアの分野では、スループットや柔軟なスケーリング比を使用して評価するよりも、ユーザー エクスペリエンスを使用してパフォーマンスと信頼性の特性を評価する方が、スマート コックピット ソフトウェアの設計目標とより一致していることは明らかです。 2. 指標システムを通じてアーキテクチャ上の特性を評価する 以前のソフトウェア品質モデルを分析すると、このモデルが主にソフトウェアのアーキテクチャ上の特性をどのように定義するのかがわかります。動作するべきである」 が、アーキテクチャ機能の要件を満たしていると判断するための「評価方法」については説明されていません。品質モデルのフィーチャーとサブフィーチャーは、アーキテクチャーフィーチャーの定性的記述ですが、アーキテクチャーフィーチャーを定量的に評価する方法については言及されていません。 実際、SQuaRE は品質モデルの評価フレームワークも提供しています (詳細については ISO/IEC 25020:2019 を参照): 上記の評価フレームワークは次のとおりです。本質的には、アーキテクチャー機能 (サブ機能) を評価するために、異なる重みを持つ一連の指標を使用することです。指標はいくつかの指標要素から計算でき、指標要素はソフトウェア開発活動で実装されるいくつかの測定方法を通じて測定できます。 ソフトウェア業界では、応答時間、スループット、RTO、RPO、MTTR など、多くの評価指標がビジネス分野全体で合意に達することができ、企業が独自の指標システムを確立する際に直接採用できます。ビジネス分野。 次に、比較的一般的なソフトウェアのパフォーマンスと信頼性の指標の例をいくつか示します。これらはほとんどのソフトウェアに適用できます。 もちろん、機能分野や動作環境の違いにより、アーキテクチャの特性を評価するために使用される指標システムには一定の違いが存在するはずです。 まず第一に、ビジネス シナリオが異なれば、評価指標の重み設定も異なります。例えば、スマートコックピットシステムやソフトウェアの性能効率評価では、ユーザーの運転体験に関わる時間特性が重要であり、インターネットサービスを提供するWebアプリケーションでは、より多くのユーザーにサービスを提供するために、容量特性も重要となる。焦点に注意を払いました。 第二に、特定の領域には独自のパフォーマンス指標があります。これらの差異指標は実際のビジネスから抽出する必要があります。例えば、UIインターフェースの流暢性は応答時間だけで評価することはできず、フレームレートやフレーム落ち数などの指標で総合的に判断する必要があります。 3. インジケーター要素のデータ ソースを見つける インジケーター システムを確立した後の次の問題は、インジケーター値を計算するための適切なインジケーター要素を見つける方法です。 同様に、循環的複雑度、モジュール結合、CPU 使用率、メモリ使用量、トランザクション実行時間、同時実行性など、直接採用できる一般的な指標要素が多数あります。ただし、指標要素は指標自体よりもビジネス分野との関連性が高く、適切な指標要素を見つけるにはドメインの知識を組み合わせる必要があります。GQM手法は指標要素の発見と確立に有効な分析手法です:GQMとは「Goal - Question - Metrics」の略で、「目標-質問-指標」と訳せます。歴史. 1984 年に Victor Basili と David Weiss によって導入されました。
基本的に、GQM はツリーを通じて階層ごとに構造を分析します。まず、目標を達成する方法に基づいて目標について質問し、次に各質問を問題の解決策をサポートできる複数の指標要素に分解し、最後に最も適切な指標要素を選択します。
以下では、「スマートコックピットのホーム画面操作のスムーズさの評価」と「スマートコックピットの故障計算」に基づいて、それぞれ「スマートコックピットソフトウェアの性能と信頼性特性を把握するための評価指標要素」を例に挙げて説明します。コックピット システムとアプリケーション」「レートと可用性」を目標として、GQM 分析ツリーを確立します。分析の初めに、アイデアを拡張するために、まず価値や取得の難易度を考慮せずに可能な限り多くの指標要素を特定し、次に各指標要素の価値と取得の難易度を分析し、優先順位付けとフィルタリングを行うことができます。最も適切なインジケーター要素。このプロセスは、次の優先順位の原則に従うことができます。
サポートできる問題が多いほど、優先順位が高くなります。
収集と計算が容易であるほど、優先順位が高くなります
GQM手法に基づいて、抽象的な指標を解体し、より明確な指標の計算式と収集されたデータポイントを取得することで、完全な評価フレームワークが完成します。
3. パフォーマンスと信頼性を継続的に向上させるためのエンジニアリング手法
1. アーキテクチャ モデリングは研究開発をガイドします
モデリングは、設計段階でビジネス ドメインとアーキテクチャの特性を分析するための効果的な手法です。ソフトウェア アーキテクチャを設計する際、多くの組織はビジネス ドメイン モデリングに重点を置き、アーキテクチャ機能モデリングを過小評価する傾向があります。その結果、セキュリティ、信頼性、パフォーマンスなどの設計上の考慮事項が舞台裏に真剣に置かれ、運用上の問題によって優先されることがよくあります。ソフトウェアのリリース後に強制的に改善されます。
実際、初期のアーキテクチャ機能モデリングは、その後の研究開発プロセスでのコード開発をガイドするだけでなく、コードが設計要件を満たしているかどうかを検証するためのホワイトボックス テストに自然に変換することもできます。
パフォーマンス モデリングの場合、ソフトウェア アーキテクチャのパフォーマンス上の懸念事項と事前定義されたパフォーマンス指標を特定することによって、パフォーマンス モデルを形成できます。パフォーマンスモデリングについては、著者が「パフォーマンスエンジニアリングとは」で紹介しています。
インジケーターシステムを使用すると、スマートコックピットソフトウェアのパフォーマンスと信頼性を定量的に分析および評価できます。ただし、評価プロセスが複雑すぎて時間がかかり、迅速に実行することが難しい場合、時間の経過とともに、これらのアーキテクチャ機能の評価がチームにとって大きな負担となり、評価アクティビティの数がますます少なくなります。フィードバックは減少し、ますます遅くなり、持続不可能になり、最終的には停滞します。
自動化できるものはすべて自動化する必要があります。
ソフトウェア機能が要件を満たしているかどうかを評価する場合、ソフトウェアが要件を満たしていることを継続的に確認するためのソフトウェア機能のセーフティ ネットを形成するために、多数の自動テストを構築します。建築上の特徴の評価に関しては、従来のアプローチは「スポーツ スタイル」の評価に似ています。
ASPICE はその典型的なケースであり、プロセスとドキュメントが複雑であることに加え、各開発段階の要件が厳しいため、設計とテストが理想的な状態に留まりがちです。以前のスナップショット バージョンでは、ソフトウェアの変更の速度に追いつくことができません。
(出典: ASPICE 概要)
ニール フォード、パトリック クア、レベッカ パーソンズの共著『進化的アーキテクチャ』では、フィットネス関数は、「意図した設計ソリューションが設定された目標の達成にどの程度近づいているかを要約する目的関数」として定義されます。適応度関数の導入は、エンジニアリング手段によってアーキテクチャの評価を自動化および正規化できることを意味します。
(出典: 「進化的アーキテクチャ」)
インジケーターとモデルがフィットネス関数に変換されると、研究開発パイプラインでバインドされます。アーキテクチャー機能の自動評価を可能にします。
自動化を前提として、アーキテクチャへの配慮を利用して継続的な改善を推進できます。
確立されたさまざまなフィットネス関数に基づいて、フィットネス関数によって生成された実行結果は、毎日のビルド、反復テスト、統合テスト、その他のプロセス中に、完全なセットのパフォーマンスと信頼性の評価レポートを形成できます。前バージョンの評価結果をベースラインとして、最新バージョンの評価結果と比較することで、ソフトウェアのパフォーマンスと信頼性を注意深く監視し、新バージョンのどの部分が最適化され、どの部分が改善されたかを判断できます。劣化が一目瞭然。
これまでのところ、継続的なパフォーマンスと信頼性の評価をサポートする手段がいくつかありますが、評価は本質的に問題の暴露、その後の分析と最適化を目的としています。継続的な改善の難しさです。
問題が明らかになったら、多くの場合、できるだけ早く最適化を実行する必要があります。ビジネス指向の組織の場合、チームはほとんどの時間をビジネス分野での作業に費やし、パフォーマンスや信頼性などの問題を分析します。 . 最適化機能が不十分な場合、通常はこの時点で、組織は改善を支援する技術専門家を探すか雇用します。しかし、技術専門家は人材が不足しているため、さまざまな問題に直面すると力尽きてしまうことがよくあります。
したがって、継続的な改善を目指す組織にとって、効率を向上させるためのエンジニアリング分析と最適化手法を確立することが不可欠です。最初の 1 つは、観察可能なツール セットを構築することです。先ほどの評価の枠組みにおいて、指標の役割は主に現状を示すことであり、指標はメリット・デメリットを評価することはできますが、問題の根本原因を分析することはできません。ソフトウェアの問題を分析するには、システムの実行時に何が起こったのか、コンポーネントがどのように相互作用するのか、どのようなデータが生成されたのかを再現できる必要があり、この情報は監視可能なツールを通じて取得および記録する必要があります。
このようなツールセットを使用した後、評価で特定の指標が悪化したことが判明した場合、システム ランタイムのコンテキストと観察記録をいくつかの基本情報に基づいて迅速に関連付けることができるため、問題を迅速に分析して特定できます。最適化を迅速に実行します。
スマートカー市場は幅広い将来性を持ち、急速に発展しており、競争が激化するにつれ、スマートコックピットの究極の体験がさまざまな自動車の主要な目標となることは間違いありません。メーカー。
この記事では、ソフトウェア開発と配信の観点から、パフォーマンスと信頼性に関するスマート コックピット ソフトウェアの継続的な評価方法と継続的な改善方法を、ソフトウェア分野の優れた実践と調査と組み合わせて主に説明します。
スマートカー分野への外部投資や分野を超えた人材の流入が増えるにつれ、今後も関連産業で大きな価値が生み出され続けると私は信じています。
以上がスマートコックピットソフトウェアの性能と信頼性の評価と改善の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。