(57)【要約】【課題】ソフトウェア開発におけるソフトウェアユニットのバージョン管理を容易にする。【解決手段】ソフトウェアファイル１０１に含まれるソフトウェアユニット１０２，１０３，１０４，１０５を備え、ソフトウェアユニット１０２，１０３，１０４，１０５は、ソフトウェアユニット１０２，１０３，１０４，１０５を識別する識別子を有し、識別子によってソフトウェアファイル１０１からソフトウェアユニット１０２，１０３，１０４，１０５が抽出される。【選択図】  図１
2019168881.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアファイルに含まれるソフトウェアユニットを備えたソフトウェア開発装置であって、
前記ソフトウェアユニットは、該ソフトウェアユニットを識別する識別子を有し、該識別子によって前記ソフトウェアファイルから前記ソフトウェアユニットが抽出される
ことを特徴とするソフトウェア開発装置。
【請求項２】
前記ソフトウェアファイルのバージョンと前記ソフトウェアユニットのバージョン情報を更新する条件であるバージョン更新条件を備え、
前記バージョン更新条件に、前記ソフトウェアファイルと前記ソフトウェアユニットの差分が該当した場合、前記ソフトウェアファイルと前記ソフトウェアユニットのバージョンを更新する
ことを特徴とする請求項１に記載のソフトウェア開発装置。
【請求項３】
前記ソフトウェアファイルのバージョンと前記ソフトウェアユニットのバージョン情報を更新する条件であるバージョン更新条件を備え、
前記バージョン更新条件に、前記ソフトウェアファイルと前記ソフトウェアユニットの差分が該当した場合、前記ソフトウェアファイルと前記ソフトウェアユニットのバージョンを更新しない
ことを特徴とする請求項１に記載のソフトウェア開発装置。
【請求項４】
前記ソフトウェアファイルのバージョンと、前記ソフトウェアユニットのバージョン情報とを定義するバージョン管理テーブルを備え、
前記ソフトウェアバージョン管理テーブルを更新することで、前記ソフトウェアファイルのバージョンを管理する
ことを特徴とする請求項２または請求項３に記載のソフトウェア開発装置。
【請求項５】
前記ソフトウェアファイルを保存するデータベースを有し、
前記バージョン管理テーブルを更新することにより、該当するバージョンの前記ソフトウェアファイルを前記データベースに登録する
ことを特徴とする請求項４に記載のソフトウェア開発装置。
【請求項６】
前記ソフトウェアファイルのバージョンと、該ソフトウェアファイルに対応する制御定数のバージョンとの組み合わせを管理する管理バージョンを備え、
前記ソフトウェアファイルのバージョン、または前記ソフトウェアファイルに対応する制御定数のバージョンが更新される場合に、前記管理バージョンを更新する
ことを特徴とする請求項５に記載のソフトウェア開発装置。
【請求項７】
前記ソフトウェアユニットのバージョンと、該ソフトウェアユニットに対応する制御定数のバージョンをバージョン管理テーブルで管理し、
前記ソフトウェアユニットのバージョンと、前記ソフトウェアユニットに対応する制御定数のバージョンの組み合わせを管理する管理バージョンを備え、
前記ソフトウェアユニットのバージョン、または前記ソフトウェアユニットに対応する制御定数のバージョンが更新される場合に、前記管理バージョンを更新する
ことを特徴とする請求項５に記載のソフトウェア開発装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア開発装置に関する。
【背景技術】
【０００２】
本技術分野の背景技術として、特許文献１（特開２０１５-１６２２１８号公報）、特許文献２（特開平０９−２５８９６４号公報）及び特許文献３（特開平０５−２７４１２１号公報）がある。
【０００３】
特許文献１の要約欄には、「図形言語で記述された制御ロジックを作成する。制御ロジックの各バージョンに対応するコメントを生成する。制御ロジックをバイナリ形式で記述したモデルファイルをバージョン管理システムのリポジトリに登録するための登録操作に応じて、モデルファイルの各バージョンに対応づけてコメントをリポジトリに格納する。」ことが開示されている。
【０００４】
特許文献２の要約欄には、「帳票ＤＢとバージョンＤＢ間でインターフェイスを取り、互いに同期しながら参照し合う機能をシステムに持たせ、ソフトウェアの変更、帳票の登録・更新する度に、両ＤＢを同時に更新し、ＤＢ間の一致性を保証し、帳票を主体にしたバージョン管理を可能にする。」ことが開示されている。
【０００５】
特許文献３の要約欄には、「プログラム更新時にＳ２でプログラム識別子をキーとして更新対象プログラムの全バージョンの構成モジュールを検索し、次いでＳ３で更新対象プログラムを構成する最新のバージョンのモジュールを検索してこれによりＳ４で更新用ファイルを作成してプログラムの更新を行なう。」ことが開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１５-１６２２１８号公報
【特許文献２】特開平０９−２５８９６４号公報
【特許文献３】特開平０５−２７４１２１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
車両制御装置のソフトウェアにおいては、開発したモデルは、車載用マイクロコンピュータ（以下、マイコン）に組込むために、モデルからマイコンに組込み可能な形式のソフトウェアに変換する。モデルに差分があった場合においても、変換後ソフトウェアに差分がないことがある。変換後ソフトウェアに差分がない場合、帳票やファイル名で管理しているモデルのバージョンを変更すると、マイコンと、このマイコンに組込んだソフトウェアの整合性確保が複雑になる。
【０００８】
また、車両制御装置においては、車両性能を満たすための制御定数や、OBD（On-Board Diagnostics）規制用の制御定数など、設定した制御定数が重要である。これらの制御定数のバージョン管理は元より、モデルを用いたシミュレーションの際に、実動作に則した制御定数を設定することで、シミュレーションの精度が向上する。そのため、ソフトウェアファイルやソフトウェアユニットに対応する制御定数を一体として管理する必要がある。
【０００９】
しかし、特許文献１乃至３では、これらについて考慮されていない。
【００１０】
そこで本発明は、ソフトウェア開発におけるソフトウェアユニットのバージョン管理を容易にすることを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、上記課題を解決するために、ソフトウェアファイルに含まれるソフトウェアユニットを備えたソフトウェア開発装置であって、前記ソフトウェアユニットは、該ソフトウェアユニットを識別する識別子を有し、該識別子によって前記ソフトウェアファイルから前記ソフトウェアユニットが抽出される。
【発明の効果】
【００１２】
本発明によれば、ソフトウェア開発におけるソフトウェアユニットのバージョン管理を容易にすることができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施例における構成管理システムの構成図
【図２】ソフトウェアとソフトウェアユニットの関係性を示すブロック線図プログラム（モデル）
【図３】ファイルデータベースの構成例
【図４】構成管理手法の管理手順フロー
【図５】バージョン管理テーブル
【図６】バージョン更新条件
【図７】車両制御装置における制御定数と構成管理システム構成図
【図８】車両制御装置における制御定数をソフトウェアユニットごとに対応付けしている場合の構成管理システム構成図
【図９】車両制御装置における制御定数とソフトウェアファイルのバージョン登録手順
【図１０】ソフトウェアファイルバージョンと制御定数バージョンの組み合わせ
【発明を実施するための形態】
【００１４】
車両用組込みソフトウェアにおいて、ブロック線図の図示によるプログラミング(以下、モデリング)は開発手法の一つとして一般的である。モデリングでは、作成したブロック線図プログラム(以下、モデル)で要求機能をシミュレーションすることにより、下流工程での不具合検出による手戻りを減らし、開発工数を低減、品質を向上させている。シミュレーションでは、ソフトウェアファイルを構成する最小管理単位であるソフトウェアユニットの接続により、車両動作や制御要求を確認している。
【００１５】
ソフトウェア開発において、ソフトウェアを複数人で開発する場合、競合を避けるためやソフトウェア管理容易性のため、また、機能安全規格のトレーサビリティ対応のため、ソフトウェアを構成管理(バージョン管理)することが必要である。そこで、構成管理のヒューマンエラー防止、効率化等のため、構成管理ツールを使用することが一般的である。
【００１６】
モデリングで開発したファイル管理は、共有サーバ上でのフォルダ管理やファイル名にバージョン情報を付与し管理する方法などがある。採番の方法は帳票による手作業での取得などがある。管理粒度として、構成管理ツールを用いて、制御単位に分割したモデルをファイルごとにバージョン管理する方法がよく利用されている。
【００１７】
モデリングによるプログラム開発において、モデルを用いたシミュレーションにより、ソフトウェア開発の上流工程で要求仕様の確認を可能としている。大規模のモデルはソフトウェアユニットを複数組み合わせて実現する。またソフトウェアを流用する際は、モデルファイル単位と、ソフトウェアユニット単位で流用することの両方あり、モデルファイル単位だけでなく、ソフトウェアユニットのバージョン管理が必要である。構成管理ツールやフォルダによるファイル管理、バージョン情報をファイル名に付与する場合、ファイル単位での管理となるため、管理粒度の詳細度が不足する。
これを踏まえて、以下、本発明の実施例について、図面を用いて説明する。
【実施例１】
【００１８】
図１は、本発明の実施例における構成管理システムの構成図である。図１において、ソフトウェアファイル１０１をファイルデータベース１０６に格納し、ソフトウェアファイル１０１と、ソフトウェアファイル１０１を構成する最小管理単位であるソフトウェアユニット１０２、１０３、１０４、１０５をバージョン管理するために、バージョン更新判定部１０７を起動する。ソフトウェアファイル１０１とソフトウェアユニット１０２〜１０５のバージョンを管理しているバージョン管理テーブル１０８から、バージョン更新判定部１０７がバージョン情報を取得し、バージョン更新条件１０９に基づき、ソフトウェアファイル１０１と記ソフトウェアユニット１０２〜１０５のバージョンを更新するか判定する。
【００１９】
図２は、ソフトウェアとソフトウェアユニットの関係性を示すブロック線図プログラム（モデル）の一例である。本実施例では以下、モデルを用いて説明を進めていくが、そのほかの形式で記述されたソフトウェアにおいても適用可能である。図２において、ソフトウェアファイルであるモデル２０１は、ソフトウェアユニット２０２、２０３、２０４、２０５の４つのソフトウェアユニットで構成している、ソフトウェアユニット２０２、２０３、２０４、２０５は、四則演算子や論理演算子を表すブロックの集合で構成されている（一例がブロック２０６）。ソフトウェアユニット２０２、２０３、２０４、２０５は、命名規則（ソフトウェアユニットを識別する識別子）２０７によって識別する。図２では例として、ソフトウェアユニット名の末尾に「_unit」（識別子の一部）を付属させている。本実施例では、命名規則により抽出する単位を、ソフトウェアファイルの最小管理単位であるソフトウェアユニットとしたが、他の管理単位でも適用可能である。
【００２０】
図３は、ファイルデータベースの構成例である。図３において、ファイルデータベース１０６には、リポジトリＡ３０１とリポジトリＢ３０２の複数のリポジトリが存在している。リポジトリＡ３０１には、ディレクトリＡ３０３とディレクトリＢ３０４のように複数のディレクトリがあり、ディレクトリＡ３０３に、モデルＡ３０５とモデルＢ３０６を格納している。モデルＡ３０５の最新バージョンは「Ｖｅｒ．０１２」であり、旧バージョン（「Ｖｅｒ．０１１」など）も、最新バージョンと同様にディレクトリＡ３０３に格納されている。
【００２１】
図４は、構成管理手法の管理フローである。
【００２２】
ステップ４０１で、ソフトウェア開発者はソフトウェアファイルを変更する。
【００２３】
ステップ４０２で、変更したソフトウェアファイルのバージョン取得し、ファイルデータベースに格納するために、構成管理ツールに対し、ファイルデータベースへ登録依頼する。
【００２４】
ステップ４０３で、登録依頼したソフトウェアファイルからあらかじめ設定した命名規則を基に、ソフトウェアユニットを抽出する。
【００２５】
ステップ４０４で、バージョン更新判定を実施するツールを自動で起動する。
【００２６】
ステップ４０５で、あらかじめ登録したバージョン更新条件を取得する。以下ステップでは、バージョン更新条件に該当した際にバージョンを更新する例について記載する。
【００２７】
ステップ４０６で、バージョン更新テーブルからソフトウェアのバージョンを取得する。
【００２８】
ステップ４０７で、バージョン更新テーブルの情報を基に、バージョンが付与されているソフトウェアファイルをファイルデータベースから取得する。
【００２９】
ステップ４０８で、ステップ４０２で登録依頼したソフトウェアとステップ４０７で取得したソフトウェアの差分が、ステップ４０５で取得したバージョン更新判定に該当するか判定する。バージョン更新ありと判定した場合はステップ４０９、バージョン更新なしと判定した場合はステップ４１０にそれぞれ進む。
【００３０】
ステップ４０９で、ステップ４０８でバージョン更新ありと判定したソフトウェアのバージョンをバージョン管理テーブルの情報から採番し、バージョン管理テーブルにソフトウェアのバージョンを反映する。
【００３１】
ステップ４１０で、ステップ４０２で登録依頼したソフトウェアファイルをファイルデータベースに格納する。
【００３２】
図５にバージョン管理テーブルの一例を示す。図５において、バージョン管理テーブルはソフトウェアファイル５０１（図５ではモデルＡ）と、ソフトウェアファイル５０１に所属しているソフトウェアユニット５０２で構成されている。ソフトウェアファイル５０１のバージョン５０３は、バージョン５０３のベースバージョン５０４（図５では親バージョン）から変更されている。ソフトウェアファイル５０１に所属するソフトウェアユニット５０２のバージョン５０５は、対応するソフトウェアファイル５０１のバージョン５０３ごとに記載している。例えば、ソフトウェアファイル５０１のバージョン５０３が「１０Ｂ」のとき、ソフトウェアユニット「DDD_unit」のバージョン５０５は「Ｖｅｒ．０４０」である。
【００３３】
図６にバージョン更新条件の一例を示す。ソフトウェアのバージョン更新判定時に、ベースソフトウェアとの差分がバージョン更新除外条件群６０１のみの場合、ソフトウェアのバージョン更新をしない。バージョン更新除外条件群６０１はバージョン更新除外条件１ ６０２、バージョン更新除外条件２ ６０３、バージョン更新除外条件６０４の複数のバージョン除外条件で構成されている。また、ソフトウェアのバージョン更新時に、ベースソフトウェアとの差分がバージョン更新条件群６０５に該当した場合、ソフトウェアのバージョンを更新する。バージョン更新条件群６０５についても、バージョン除外条件群６０１と同様に、バージョン更新条件６０６、６０７、６０８の複数の条件で構成されている。
【実施例２】
【００３４】
次に実施例２について、図７、図８、図９、図１０を用いて説明する。
【００３５】
図７は、車両制御装置における制御定数と構成管理システム構成図である。図７において、制御定数７０１はソフトウェアファイル１０１に対応したファイルであり、ファイルデータベース１０６に保存している。制御定数７０１のバージョンはバージョン管理テーブル１０８で管理している。さらに、ソフトウェアファイル１０１と制御定数７０１の組み合わせ７０２に対応するバージョンもバージョン管理テーブル１０８で管理する。
【００３６】
図８は、車両制御装置における制御定数をソフトウェアユニットごとに対応付けしている場合の構成管理システム構成図である。図８において、制御定数８０１はソフトウェアファイル１０１に所属しているソフトウェアユニット１０２に対応したファイルであり、ファイルデータベース１０６に格納している。制御定数８０１のバージョンはバージョン管理テーブル１０８で管理している。さらに、ソフトウェアユニット１０２と制御定数８０１の組み合わせ８０２に対応するバージョンも、バージョン管理テーブル１０８で管理する。
【００３７】
図９は、車両制御装置における制御定数とソフトウェアファイルのバージョン登録手順である。ここでは、制御定数をソフトウェアファイルに対応付けている場合について説明するが、ソフトウェアユニットに対応付けた場合も同様である。図９において、ステップ４０１からステップ４１０の手順については、実施例１と同様であるため、説明を省略する。
【００３８】
ステップ９０１で、バージョン管理テーブルから、制御定数のバージョン情報を取得する。
【００３９】
ステップ９０２で、ステップ４０９でバージョン管理テーブルに反映したソフトウェアファイルバージョンと、ステップ９０１で取得した制御定数バージョンの組み合わせが、既にバージョン管理テーブルに登録されているか確認する。組み合わせバージョンが既にバージョン管理テーブルに登録されていた場合、バージョン更新処理を終了する。組み合わせバージョンがバージョン管理テーブルに登録されていない場合、ステップ９０３に進む。
【００４０】
ステップ９０３では、バージョン管理テーブルにステップ４０９でバージョン管理テーブルに反映したソフトウェアファイルバージョンと、ステップ９０１で取得した制御定数バージョンの組み合わせバージョンを反映する。
【００４１】
図１０は、ソフトウェアファイルバージョンと制御定数バージョンの組み合わせに対するバージョン管理テーブルである。組み合わせバージョン１００１は、ソフトウェアバージョン１００２と制御定数バージョン１００３の組み合わせの数だけ存在する。例えば、ソフトウェアバージョンが１０Ｂで、制御定数バージョンが０４０である場合、組み合わせのバージョンは１０Ｂ０４０となっている。組み合わせバージョンは、一意となるように設定する。
【００４２】
上記各実施例によれば、ソフトウェアファイルに含まれるソフトウェアユニットを備えたソフトウェア開発装置であって、前記ソフトウェアユニットは、該ソフトウェアユニットを識別する識別子を有し、該識別子によって前記ソフトウェアファイルから前記ソフトウェアユニットが抽出される。
すなわち、ソフトウェアの構成管理において、ソフトウェアを構成する最小管理単位（ソフトウェアユニット）に命名規則に基づく名前（識別子）を付けることにより、複数のソフトウェアユニットを有しているファイルにおいて、ソフトウェアユニットを判別することができる。
【００４３】
また、前記ソフトウェアファイルのバージョンと前記ソフトウェアユニットのバージョン情報を更新する条件であるバージョン更新条件を備え、前記バージョン更新条件に、前記ソフトウェアファイルと前記ソフトウェアユニットの差分が該当した場合、前記ソフトウェアファイルと前記ソフトウェアユニットのバージョンを更新する。
【００４４】
また、前記ソフトウェアファイルのバージョンと前記ソフトウェアユニットのバージョン情報を更新する条件であるバージョン更新条件を備え、前記バージョン更新条件に、前記ソフトウェアファイルと前記ソフトウェアユニットの差分が該当した場合、前記ソフトウェアファイルと前記ソフトウェアユニットのバージョンを更新しない。
【００４５】
また、前記ソフトウェアファイルのバージョンと、前記ソフトウェアユニットのバージョン情報とを定義するバージョン管理テーブルを備え、前記ソフトウェアバージョン管理テーブルを更新することで、前記ソフトウェアファイルのバージョンを管理する。
【００４６】
また、前記ソフトウェアファイルを保存するデータベースを有し、前記ソフトウェアバージョン管理テーブルを更新することにより、該当するバージョンの前記ソフトウェアファイルを前記データベースに登録する。
【００４７】
また、前記ソフトウェアファイルのバージョンと、該ソフトウェアファイルに対応する制御定数のバージョンとの組み合わせを管理する管理バージョンを備え、前記ソフトウェアファイルのバージョン、または前記ソフトウェアファイルに対応する制御定数のバージョンが更新される場合に、前記管理バージョンを更新する。
【００４８】
また、前記ソフトウェアユニットのバージョンと、該ソフトウェアユニットに対応する制御定数のバージョンをバージョン管理テーブルで管理し、前記ソフトウェアユニットのバージョンと、前記ソフトウェアユニットに対応する制御定数のバージョンの組み合わせを管理する管理バージョンを備え、前記ソフトウェアユニットのバージョン、または前記ソフトウェアユニットに対応する制御定数のバージョンが更新される場合に、前記管理バージョンを更新する。
【００４９】
以上から、ソフトウェアユニットの構造に対し、バージョンアップ条件を基に解析することにより、ソフトウェアユニットごとのバージョン管理が可能となる。
【符号の説明】
【００５０】
１０１  ソフトウェアファイル、１０２  ソフトウェアユニットＡ、１０３  ソフトウェアユニットＢ、１０４  ソフトウェアユニットＣ、１０５  ソフトウェアユニットＤ、１０６  ファイルデータベース、１０７  バージョン更新判定部、１０８  バージョン管理テーブル、１０９  バージョン更新条件、２０１  ソフトウェアファイル、２０２〜２０５  ソフトウェアユニット、２０６  制御ブロック、２０７  ソフトウェアユニット命名規則、３０１  リポジトリＡ、３０２  リポジトリＢ、３０３  ディレクトリＡ、３０４  ディレクトリＢ、３０５  モデルＡ、３０６  モデルＢ、５０１  ソフトウェアファイル名、５０２  ソフトウェアユニット名一覧、５０３  ソフトウェアファイルバージョン、５０４  ベースソフトウェアバージョン、５０５  ソフトウェアユニットバージョン一覧、６０１  バージョン更新除外条件群の例、６０２  バージョン更新除外条件１、６０３  バージョン更新除外条件２、６０４  バージョン更新除外条件、６０５  バージョン更新条件群の例、６０６  バージョン更新条件１、６０７  バージョン更新条件２、６０８  バージョン更新条件、７０１  ソフトウェアファイルに対応する制御定数、７０２  ソフトウェアファイルと制御定数の組み合わせ、８０１  ソフトウェアユニットに対応する制御定数、８０２  ソフトウェアユニットと制御定数の組み合わせ、１００１  ソフトウェアファイルと制御定数の組み合わせバージョン、１００２  ソフトウェアファイルバージョン、１００３  制御定数バージョン
【図１】
2019168881.tif 000003
【図２】
2019168881.tif 000004
【図３】
2019168881.tif 000005
【図４】
2019168881.tif 000006
【図５】
2019168881.tif 000007
【図６】
2019168881.tif 000008
【図７】
2019168881.tif 000009
【図８】
2019168881.tif 000010
【図９】
2019168881.tif 000011
【図１０】
2019168881.tif 000012