JP6945481B2

JP6945481B2 - ソフトウェア開発装置

Info

Publication number: JP6945481B2
Application number: JP2018055528A
Authority: JP
Inventors: 天馬田村; 健太郎宍戸
Original assignee: Hitachi Astemo Ltd
Current assignee: Hitachi Astemo Ltd
Priority date: 2018-03-23
Filing date: 2018-03-23
Publication date: 2021-10-06
Anticipated expiration: 2038-03-23
Also published as: JP2019168881A

Description

本発明は、ソフトウェア開発装置に関する。

本技術分野の背景技術として、特許文献１（特開２０１５-１６２２１８号公報）、特許文献２（特開平０９−２５８９６４号公報）及び特許文献３（特開平０５−２７４１２１号公報）がある。

特許文献１の要約欄には、「図形言語で記述された制御ロジックを作成する。制御ロジックの各バージョンに対応するコメントを生成する。制御ロジックをバイナリ形式で記述したモデルファイルをバージョン管理システムのリポジトリに登録するための登録操作に応じて、モデルファイルの各バージョンに対応づけてコメントをリポジトリに格納する。」ことが開示されている。

特許文献２の要約欄には、「帳票ＤＢとバージョンＤＢ間でインターフェイスを取り、互いに同期しながら参照し合う機能をシステムに持たせ、ソフトウェアの変更、帳票の登録・更新する度に、両ＤＢを同時に更新し、ＤＢ間の一致性を保証し、帳票を主体にしたバージョン管理を可能にする。」ことが開示されている。

特許文献３の要約欄には、「プログラム更新時にＳ２でプログラム識別子をキーとして更新対象プログラムの全バージョンの構成モジュールを検索し、次いでＳ３で更新対象プログラムを構成する最新のバージョンのモジュールを検索してこれによりＳ４で更新用ファイルを作成してプログラムの更新を行なう。」ことが開示されている。

特開２０１５-１６２２１８号公報特開平０９−２５８９６４号公報特開平０５−２７４１２１号公報

車両制御装置のソフトウェアにおいては、開発したモデルは、車載用マイクロコンピュータ（以下、マイコン）に組込むために、モデルからマイコンに組込み可能な形式のソフトウェアに変換する。モデルに差分があった場合においても、変換後ソフトウェアに差分がないことがある。変換後ソフトウェアに差分がない場合、帳票やファイル名で管理しているモデルのバージョンを変更すると、マイコンと、このマイコンに組込んだソフトウェアの整合性確保が複雑になる。

また、車両制御装置においては、車両性能を満たすための制御定数や、OBD（On-Board Diagnostics）規制用の制御定数など、設定した制御定数が重要である。これらの制御定数のバージョン管理は元より、モデルを用いたシミュレーションの際に、実動作に則した制御定数を設定することで、シミュレーションの精度が向上する。そのため、ソフトウェアファイルやソフトウェアユニットに対応する制御定数を一体として管理する必要がある。

しかし、特許文献１乃至３では、これらについて考慮されていない。

そこで本発明は、ソフトウェア開発におけるソフトウェアユニットのバージョン管理を容易にすることを目的とする。

本発明は、上記課題を解決するために、ソフトウェアファイルに含まれるソフトウェアユニットを備えたソフトウェア開発装置であって、前記ソフトウェアユニットは、該ソフトウェアユニットを識別する識別子を有し、該識別子によって前記ソフトウェアファイルから前記ソフトウェアユニットが抽出される。

本発明によれば、ソフトウェア開発におけるソフトウェアユニットのバージョン管理を容易にすることができる。

本発明の実施例における構成管理システムの構成図ソフトウェアとソフトウェアユニットの関係性を示すブロック線図プログラム（モデル）ファイルデータベースの構成例構成管理手法の管理手順フローバージョン管理テーブルバージョン更新条件車両制御装置における制御定数と構成管理システム構成図車両制御装置における制御定数をソフトウェアユニットごとに対応付けしている場合の構成管理システム構成図車両制御装置における制御定数とソフトウェアファイルのバージョン登録手順ソフトウェアファイルバージョンと制御定数バージョンの組み合わせ

車両用組込みソフトウェアにおいて、ブロック線図の図示によるプログラミング(以下、モデリング)は開発手法の一つとして一般的である。モデリングでは、作成したブロック線図プログラム(以下、モデル)で要求機能をシミュレーションすることにより、下流工程での不具合検出による手戻りを減らし、開発工数を低減、品質を向上させている。シミュレーションでは、ソフトウェアファイルを構成する最小管理単位であるソフトウェアユニットの接続により、車両動作や制御要求を確認している。

ソフトウェア開発において、ソフトウェアを複数人で開発する場合、競合を避けるためやソフトウェア管理容易性のため、また、機能安全規格のトレーサビリティ対応のため、ソフトウェアを構成管理(バージョン管理)することが必要である。そこで、構成管理のヒューマンエラー防止、効率化等のため、構成管理ツールを使用することが一般的である。

モデリングで開発したファイル管理は、共有サーバ上でのフォルダ管理やファイル名にバージョン情報を付与し管理する方法などがある。採番の方法は帳票による手作業での取得などがある。管理粒度として、構成管理ツールを用いて、制御単位に分割したモデルをファイルごとにバージョン管理する方法がよく利用されている。

モデリングによるプログラム開発において、モデルを用いたシミュレーションにより、ソフトウェア開発の上流工程で要求仕様の確認を可能としている。大規模のモデルはソフトウェアユニットを複数組み合わせて実現する。またソフトウェアを流用する際は、モデルファイル単位と、ソフトウェアユニット単位で流用することの両方あり、モデルファイル単位だけでなく、ソフトウェアユニットのバージョン管理が必要である。構成管理ツールやフォルダによるファイル管理、バージョン情報をファイル名に付与する場合、ファイル単位での管理となるため、管理粒度の詳細度が不足する。
これを踏まえて、以下、本発明の実施例について、図面を用いて説明する。

図１は、本発明の実施例における構成管理システムの構成図である。図１において、ソフトウェアファイル１０１をファイルデータベース１０６に格納し、ソフトウェアファイル１０１と、ソフトウェアファイル１０１を構成する最小管理単位であるソフトウェアユニット１０２、１０３、１０４、１０５をバージョン管理するために、バージョン更新判定部１０７を起動する。ソフトウェアファイル１０１とソフトウェアユニット１０２〜１０５のバージョンを管理しているバージョン管理テーブル１０８から、バージョン更新判定部１０７がバージョン情報を取得し、バージョン更新条件１０９に基づき、ソフトウェアファイル１０１と記ソフトウェアユニット１０２〜１０５のバージョンを更新するか判定する。

図２は、ソフトウェアとソフトウェアユニットの関係性を示すブロック線図プログラム（モデル）の一例である。本実施例では以下、モデルを用いて説明を進めていくが、そのほかの形式で記述されたソフトウェアにおいても適用可能である。図２において、ソフトウェアファイルであるモデル２０１は、ソフトウェアユニット２０２、２０３、２０４、２０５の４つのソフトウェアユニットで構成している、ソフトウェアユニット２０２、２０３、２０４、２０５は、四則演算子や論理演算子を表すブロックの集合で構成されている（一例がブロック２０６）。ソフトウェアユニット２０２、２０３、２０４、２０５は、命名規則（ソフトウェアユニットを識別する識別子）２０７によって識別する。図２では例として、ソフトウェアユニット名の末尾に「_unit」（識別子の一部）を付属させている。本実施例では、命名規則により抽出する単位を、ソフトウェアファイルの最小管理単位であるソフトウェアユニットとしたが、他の管理単位でも適用可能である。

図３は、ファイルデータベースの構成例である。図３において、ファイルデータベース１０６には、リポジトリＡ３０１とリポジトリＢ３０２の複数のリポジトリが存在している。リポジトリＡ３０１には、ディレクトリＡ３０３とディレクトリＢ３０４のように複数のディレクトリがあり、ディレクトリＡ３０３に、モデルＡ３０５とモデルＢ３０６を格納している。モデルＡ３０５の最新バージョンは「Ｖｅｒ．０１２」であり、旧バージョン（「Ｖｅｒ．０１１」など）も、最新バージョンと同様にディレクトリＡ３０３に格納されている。

図４は、構成管理手法の管理フローである。

ステップ４０１で、ソフトウェア開発者はソフトウェアファイルを変更する。

ステップ４０２で、変更したソフトウェアファイルのバージョン取得し、ファイルデータベースに格納するために、構成管理ツールに対し、ファイルデータベースへ登録依頼する。

ステップ４０３で、登録依頼したソフトウェアファイルからあらかじめ設定した命名規則を基に、ソフトウェアユニットを抽出する。

ステップ４０４で、バージョン更新判定を実施するツールを自動で起動する。

ステップ４０５で、あらかじめ登録したバージョン更新条件を取得する。以下ステップでは、バージョン更新条件に該当した際にバージョンを更新する例について記載する。

ステップ４０６で、バージョン更新テーブルからソフトウェアのバージョンを取得する。

ステップ４０７で、バージョン更新テーブルの情報を基に、バージョンが付与されているソフトウェアファイルをファイルデータベースから取得する。

ステップ４０８で、ステップ４０２で登録依頼したソフトウェアとステップ４０７で取得したソフトウェアの差分が、ステップ４０５で取得したバージョン更新判定に該当するか判定する。バージョン更新ありと判定した場合はステップ４０９、バージョン更新なしと判定した場合はステップ４１０にそれぞれ進む。

ステップ４０９で、ステップ４０８でバージョン更新ありと判定したソフトウェアのバージョンをバージョン管理テーブルの情報から採番し、バージョン管理テーブルにソフトウェアのバージョンを反映する。

ステップ４１０で、ステップ４０２で登録依頼したソフトウェアファイルをファイルデータベースに格納する。

図５にバージョン管理テーブルの一例を示す。図５において、バージョン管理テーブルはソフトウェアファイル５０１（図５ではモデルＡ）と、ソフトウェアファイル５０１に所属しているソフトウェアユニット５０２で構成されている。ソフトウェアファイル５０１のバージョン５０３は、バージョン５０３のベースバージョン５０４（図５では親バージョン）から変更されている。ソフトウェアファイル５０１に所属するソフトウェアユニット５０２のバージョン５０５は、対応するソフトウェアファイル５０１のバージョン５０３ごとに記載している。例えば、ソフトウェアファイル５０１のバージョン５０３が「１０Ｂ」のとき、ソフトウェアユニット「DDD_unit」のバージョン５０５は「Ｖｅｒ．０４０」である。

図６にバージョン更新条件の一例を示す。ソフトウェアのバージョン更新判定時に、ベースソフトウェアとの差分がバージョン更新除外条件群６０１のみの場合、ソフトウェアのバージョン更新をしない。バージョン更新除外条件群６０１はバージョン更新除外条件１６０２、バージョン更新除外条件２６０３、バージョン更新除外条件６０４の複数のバージョン除外条件で構成されている。また、ソフトウェアのバージョン更新時に、ベースソフトウェアとの差分がバージョン更新条件群６０５に該当した場合、ソフトウェアのバージョンを更新する。バージョン更新条件群６０５についても、バージョン除外条件群６０１と同様に、バージョン更新条件６０６、６０７、６０８の複数の条件で構成されている。

次に実施例２について、図７、図８、図９、図１０を用いて説明する。

図７は、車両制御装置における制御定数と構成管理システム構成図である。図７において、制御定数７０１はソフトウェアファイル１０１に対応したファイルであり、ファイルデータベース１０６に保存している。制御定数７０１のバージョンはバージョン管理テーブル１０８で管理している。さらに、ソフトウェアファイル１０１と制御定数７０１の組み合わせ７０２に対応するバージョンもバージョン管理テーブル１０８で管理する。

図８は、車両制御装置における制御定数をソフトウェアユニットごとに対応付けしている場合の構成管理システム構成図である。図８において、制御定数８０１はソフトウェアファイル１０１に所属しているソフトウェアユニット１０２に対応したファイルであり、ファイルデータベース１０６に格納している。制御定数８０１のバージョンはバージョン管理テーブル１０８で管理している。さらに、ソフトウェアユニット１０２と制御定数８０１の組み合わせ８０２に対応するバージョンも、バージョン管理テーブル１０８で管理する。

図９は、車両制御装置における制御定数とソフトウェアファイルのバージョン登録手順である。ここでは、制御定数をソフトウェアファイルに対応付けている場合について説明するが、ソフトウェアユニットに対応付けた場合も同様である。図９において、ステップ４０１からステップ４１０の手順については、実施例１と同様であるため、説明を省略する。

ステップ９０１で、バージョン管理テーブルから、制御定数のバージョン情報を取得する。

ステップ９０２で、ステップ４０９でバージョン管理テーブルに反映したソフトウェアファイルバージョンと、ステップ９０１で取得した制御定数バージョンの組み合わせが、既にバージョン管理テーブルに登録されているか確認する。組み合わせバージョンが既にバージョン管理テーブルに登録されていた場合、バージョン更新処理を終了する。組み合わせバージョンがバージョン管理テーブルに登録されていない場合、ステップ９０３に進む。

ステップ９０３では、バージョン管理テーブルにステップ４０９でバージョン管理テーブルに反映したソフトウェアファイルバージョンと、ステップ９０１で取得した制御定数バージョンの組み合わせバージョンを反映する。

図１０は、ソフトウェアファイルバージョンと制御定数バージョンの組み合わせに対するバージョン管理テーブルである。組み合わせバージョン１００１は、ソフトウェアバージョン１００２と制御定数バージョン１００３の組み合わせの数だけ存在する。例えば、ソフトウェアバージョンが１０Ｂで、制御定数バージョンが０４０である場合、組み合わせのバージョンは１０Ｂ０４０となっている。組み合わせバージョンは、一意となるように設定する。

上記各実施例によれば、ソフトウェアファイルに含まれるソフトウェアユニットを備えたソフトウェア開発装置であって、前記ソフトウェアユニットは、該ソフトウェアユニットを識別する識別子を有し、該識別子によって前記ソフトウェアファイルから前記ソフトウェアユニットが抽出される。
すなわち、ソフトウェアの構成管理において、ソフトウェアを構成する最小管理単位（ソフトウェアユニット）に命名規則に基づく名前（識別子）を付けることにより、複数のソフトウェアユニットを有しているファイルにおいて、ソフトウェアユニットを判別することができる。

また、前記ソフトウェアファイルのバージョンと前記ソフトウェアユニットのバージョン情報を更新する条件であるバージョン更新条件を備え、前記バージョン更新条件に、前記ソフトウェアファイルと前記ソフトウェアユニットの差分が該当した場合、前記ソフトウェアファイルと前記ソフトウェアユニットのバージョンを更新する。

また、前記ソフトウェアファイルのバージョンと前記ソフトウェアユニットのバージョン情報を更新する条件であるバージョン更新条件を備え、前記バージョン更新条件に、前記ソフトウェアファイルと前記ソフトウェアユニットの差分が該当した場合、前記ソフトウェアファイルと前記ソフトウェアユニットのバージョンを更新しない。

また、前記ソフトウェアファイルのバージョンと、前記ソフトウェアユニットのバージョン情報とを定義するバージョン管理テーブルを備え、前記ソフトウェアバージョン管理テーブルを更新することで、前記ソフトウェアファイルのバージョンを管理する。

また、前記ソフトウェアファイルを保存するデータベースを有し、前記ソフトウェアバージョン管理テーブルを更新することにより、該当するバージョンの前記ソフトウェアファイルを前記データベースに登録する。

また、前記ソフトウェアファイルのバージョンと、該ソフトウェアファイルに対応する制御定数のバージョンとの組み合わせを管理する管理バージョンを備え、前記ソフトウェアファイルのバージョン、または前記ソフトウェアファイルに対応する制御定数のバージョンが更新される場合に、前記管理バージョンを更新する。

また、前記ソフトウェアユニットのバージョンと、該ソフトウェアユニットに対応する制御定数のバージョンをバージョン管理テーブルで管理し、前記ソフトウェアユニットのバージョンと、前記ソフトウェアユニットに対応する制御定数のバージョンの組み合わせを管理する管理バージョンを備え、前記ソフトウェアユニットのバージョン、または前記ソフトウェアユニットに対応する制御定数のバージョンが更新される場合に、前記管理バージョンを更新する。

以上から、ソフトウェアユニットの構造に対し、バージョンアップ条件を基に解析することにより、ソフトウェアユニットごとのバージョン管理が可能となる。

１０１ソフトウェアファイル、１０２ソフトウェアユニットＡ、１０３ソフトウェアユニットＢ、１０４ソフトウェアユニットＣ、１０５ソフトウェアユニットＤ、１０６ファイルデータベース、１０７バージョン更新判定部、１０８バージョン管理テーブル、１０９バージョン更新条件、２０１ソフトウェアファイル、２０２〜２０５ソフトウェアユニット、２０６制御ブロック、２０７ソフトウェアユニット命名規則、３０１リポジトリＡ、３０２リポジトリＢ、３０３ディレクトリＡ、３０４ディレクトリＢ、３０５モデルＡ、３０６モデルＢ、５０１ソフトウェアファイル名、５０２ソフトウェアユニット名一覧、５０３ソフトウェアファイルバージョン、５０４ベースソフトウェアバージョン、５０５ソフトウェアユニットバージョン一覧、６０１バージョン更新除外条件群の例、６０２バージョン更新除外条件１、６０３バージョン更新除外条件２、６０４バージョン更新除外条件、６０５バージョン更新条件群の例、６０６バージョン更新条件１、６０７バージョン更新条件２、６０８バージョン更新条件、７０１ソフトウェアファイルに対応する制御定数、７０２ソフトウェアファイルと制御定数の組み合わせ、８０１ソフトウェアユニットに対応する制御定数、８０２ソフトウェアユニットと制御定数の組み合わせ、１００１ソフトウェアファイルと制御定数の組み合わせバージョン、１００２ソフトウェアファイルバージョン、１００３制御定数バージョン

Claims

ソフトウェアファイルに含まれるソフトウェアユニットを備えたソフトウェア開発装置であって、
前記ソフトウェアユニットは、該ソフトウェアユニットを識別する識別子を有し、該識別子によって前記ソフトウェアファイルから前記ソフトウェアユニットが抽出され、
前記ソフトウェアファイルのバージョンと前記ソフトウェアユニットのバージョン情報を更新する条件であるバージョン更新条件を備え、
前記バージョン更新条件に、前記ソフトウェアファイルと前記ソフトウェアユニットの差分が該当した場合、前記ソフトウェアファイルと前記ソフトウェアユニットのバージョンを更新することを特徴とするソフトウェア開発装置。
前記ソフトウェアファイルのバージョンと前記ソフトウェアユニットのバージョン情報を更新しない条件であるバージョン更新除外条件を備え、
前記バージョン更新除外条件に、前記ソフトウェアファイルと前記ソフトウェアユニットの差分が該当した場合、前記ソフトウェアファイルと前記ソフトウェアユニットのバージョンを更新しない
ことを特徴とする請求項１に記載のソフトウェア開発装置。
前記ソフトウェアファイルのバージョンと、前記ソフトウェアユニットのバージョン情報とを定義するバージョン管理テーブルを備え、
前記ソフトウェアバージョン管理テーブルを更新することで、前記ソフトウェアファイルのバージョンを管理する
ことを特徴とする請求項２に記載のソフトウェア開発装置。
前記ソフトウェアファイルを保存するデータベースを有し、
前記バージョン管理テーブルを更新することにより、該当するバージョンの前記ソフトウェアファイルを前記データベースに登録する
ことを特徴とする請求項３に記載のソフトウェア開発装置。
前記ソフトウェアファイルのバージョンと、該ソフトウェアファイルに対応する制御定数のバージョンとの組み合わせを管理する管理バージョンを備え、
前記ソフトウェアファイルのバージョン、または前記ソフトウェアファイルに対応する制御定数のバージョンが更新される場合に、前記管理バージョンを更新する
ことを特徴とする請求項４に記載のソフトウェア開発装置。
前記ソフトウェアユニットのバージョンと、該ソフトウェアユニットに対応する制御定数のバージョンをバージョン管理テーブルで管理し、
前記ソフトウェアユニットのバージョンと、前記ソフトウェアユニットに対応する制御定数のバージョンの組み合わせを管理する管理バージョンを備え、
前記ソフトウェアユニットのバージョン、または前記ソフトウェアユニットに対応する制御定数のバージョンが更新される場合に、前記管理バージョンを更新する
ことを特徴とする請求項４に記載のソフトウェア開発装置。