はじめまして、QINeSサービスセンター部の蒲原です。私は入社して以来、約3年間AUTOSAR Classic Platform(以下、Classic Platform)、その後AUTOSAR Adaptive Platform(以下、Adaptive Platform) の活動に携わっています。本記事では組み込み開発やClassicPlatformの開発に従事している方を対象に、私がAdaptive PlatformのWGの活動や開発に携わったときに感じた特徴を紹介し、少しでもAdaptive Platformについて興味を持って頂けると嬉しいです。
なぜAdaptive Platformの活動を始めたのか
2021年現在、SCSKではClassic Platform領域向けにQINeSというブランドでBSWやToolなど幅広くソリューションを提供しています。私の入社時の配属先はQINeSの部署でしたが、当時は部署が設立されて日が浅く、様々なツールの検証や導入からのスタートでした。QINeSの一番最初のインテグレーション作業を担当させて頂いたとき、自身のC言語のスキル不足とClassic Platformの複雑さに苦戦したのは苦い思い出です。
さて、2016年にPOSIXベースのAdaptive Platformのコンセプトが発表されました。コネクテッドやOTAなど、Classic Platformでは将来変化し続けるニーズに対応していくことが難しいため、新しいプラットフォームとしてAdaptive Platformが立ち上げられました。Adaptive PlatformはClassic Platformを置き換えるものではなくお互いに協調しながら車載システムを実現します。
今となっては車載業界ではAUTOSARは有名になりましたが、当時国内ではClassic Platformが徐々に広がり始めていた最中、Adaptive Platformの発表は衝撃でした。我々は今後の車載システムの動向を見極めるためにAdaptive PlatformのPremiumパートナーとなり、その中でも全体を俯瞰できるWG-AP-STに参画しAdaptive Platformに関するノウハウを蓄えてきました。
Adaptive Platformの活動を始めて感じた開発の特徴
「AUTOSAR Adaptive仕様策定ワーキンググループ活動とSCSKの取組み」(弊社の綾野の記事)ではAUTOSAR全体の仕様やWGについて紹介していますが、私はメンバとして WG 活動に参加して開発に携わっています。本稿ではAdaptive Platformの開発の特徴についてご紹介したいと思います。
● 開発プロセスの違い
組み込み業界の開発プロセスはウォーターフォールが一般的だと思いますが、Adaptive Platformではアジャイルを採用しています。アジャイルはWeb業界などでの採用が進み、組み込み業界ではあまり耳にしません。しかし、Adaptive PlatformではOSSの積極的な採用や、アーキテクチャおよびI/Fの標準化により開発効率を高める工夫をしています。実際にAdaptive Platformのリリースは6ヶ月毎のリリース(現在はメンテナンスフェーズのため1年毎)を行ってきました。このリリースにはClassic Platformのように仕様書だけではなく、リファレンス実装も含みます。
また、ここでのアジャイルは厳密にはソフトウェア開発プロセスのアジャイルではありません。チケット管理システムを用いてスプリント制を採用していますが、デイリースクリムやプランニングポーカーなどを実施しているわけではありません。あくまでも、リリース頻度の高い開発において柔軟に対応できるような仕組みという意味合いが強いです。
● 構成管理ツールについて
AUTOSAR WGではAUTOSAR本体のソースコード以外にも、仕様書やミーティングのMinutesなどのドキュメント系を管理しています。
ドキュメント系はPowerPointやPDFなどのソースコードのように差分が見えづらかったり、更新頻度が高くないためSVNで管理を行っています。Gitで管理されたソースコードもリリース時にタグが切られて、SVNでも管理されます。
ソースコードは以下の観点からGitを使ったバージョン管理を行っています。
- ・ GitHubやGitlabなどのSW開発用のプラットフォームが提供するソースコードレビュー機能を利用することで効率的なレビューを実施できる
- ・ チケット管理システムと連携して、機能追加やバグに関するコードレビューとチケットを紐付けることで関連性を追跡しやすい
- ・ CI/CDの活用
CI/CDは「Continuous Integration(継続的インテグレーション)」、「Continuous Delivery、Deployment(継続的デリバリー、デプロイメント)」と呼ばれます。
ソフトウェアの開発では設計や実装の他に「テストなどの検証フェーズ」が欠かせません。例えば、機能を追加したりバグを修正したタイミングで、静的解析や単体／結合テスト、ビルドなどの検証作業を行いますが、これが特定の開発者によって行われる場合は以下のリスクがあります。
- ・ 開発者の環境の違いによってソフトウェアの振る舞いが異なる恐れがある
- ・ 特定の作業がスキップされる恐れがある
- ・ 複数の開発者同士の開発状況が見えづらく、他の開発者との変更が競合してしまう。その結果デグレードが発生する恐れがある
ソフトウェアの規模が大きく、変更頻度が高いほど上記のリスクは無視できなくなります。
CI/CDは、実装や環境に対して行われる検証作業にトリガーを設計してクリーンな環境で自動化します。また、一定の基準を満たさない場合は本流のブランチにマージさせない運用も可能です。
上の図はCI/CDの一連の流れについて表したものです。コードレビュー機能については、GitHubやGitlabが提供する機能になっており、GitHubではPR(Pull Request)、GitlabではMR(Merge Request)と呼びます。
簡単に流れを説明します。
- １．開発者はチケット管理システムで管理された課題チケット(機能追加やバグ修正など)に対して、ブランチを作成し実装を行います
- ２．実装が完了して、ローカル環境で確認可能な内容を実施したあとに、コードレビューを作成します
- ３．コードレビューを作成したあとに、自動もしくは手動でCI/CDの実行を行います。自動の場合は結果もコードレビュー機能に反映されて関連するログへのリンクが作成されます。手動の場合は開発者が関連するログへのリンクを記載して、レビュワーにレビューを依頼します
- ４．レビュワーは、ソースコードや結果を確認して問題があれば指摘内容を記載してフィードバックします
- ５．問題がなければ変更を本体にマージします
開発者は機能をマージして反映させる前にCI/CDによるチェックを受けることになりますが、検証が通ればプロジェクトが規定する品質に達している証になります。検証が通らなかった場合も、ログが残るため、他の開発者にアドバイスをもらいやすくなります。
私が初めて担当した機能をマージする際に、開発規模は小さかったもののたくさんの指摘を頂いたのを覚えています。その中でも、エンジニアのスキルの向上やプロジェクトの品質向上のために以下のようなコメントを残してもらえたのが、「新しい開発文化に触れているな」と感動した瞬間でした。
・ その書き方でも動くけど、C++の新しい規格の書き方がスマートだよ
・ コミット粒度が細かすぎるので、適切に分けよう
さいごに
今回はAdaptive Platformでの開発の特徴について記事を書かせていただきました。ここで紹介した内容は一部ではありますが、Adaptive Platformの開発について少しでも興味を持って頂けたら嬉しく思います。SCSKはこれから採用が増えるであろうAUTOSARについてClassic PlatformおよびAdaptive Platformに関するソリューションをこれからも提案・提供し、自動車産業へ貢献していきたいと考えております。