JP4200581B2 - Software combination inspection device - Google Patents
Software combination inspection device Download PDFInfo
- Publication number
- JP4200581B2 JP4200581B2 JP08402599A JP8402599A JP4200581B2 JP 4200581 B2 JP4200581 B2 JP 4200581B2 JP 08402599 A JP08402599 A JP 08402599A JP 8402599 A JP8402599 A JP 8402599A JP 4200581 B2 JP4200581 B2 JP 4200581B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- software
- information
- design document
- processing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
この発明は、複数のソフトウェア部品（ソフトウェアモジュール）を結合することにより構成されるソフトウェアの結合検査を行うためのソフトウェア結合検査装置に関する。
【０００２】
【従来の技術】
従来より、例えばオブジェクト指向のシステム設計におけるソフトウェア開発では、複数のソフトウェア部品（オブジェクト指向では「オブジェクト」としてとらえられる）を結合することにより、所望の機能を有する新たなソフトウェアを開発することが行われている。なお、オブジェクト指向とは、人間が行動するときの如く操作対象に注目して仕事を進めるという考え方を、コンピュータシステムにモデル化したものであり、このオブジェクト指向のプログラミングでは、プログラムの処理を、オブジェクトという単位で考える。オブジェクトは、オブジェクト固有のデータとそのデータを扱う処理とを、一まとめにしたソフトウェアモジュールである。
【０００３】
オブジェクトの結合は、あるオブジェクトから別のオブジェクトに対し、特定の処理を実行して欲しい旨の「処理依頼（メッセージ）」が出力されることによって図られ、メッセージを受けたオブジェクトでは、そのメッセージにより特定される処理が行われる。従って、オブジェクトの結合により作成すべき新たなソフトウェアにて所望の機能を実現するためには、各オブジェクトからのメッセージの出力先、出力順序、出力条件等を設計（メッセージ・シーケンスの設計）することが必要となる。そしてメッセージ・シーケンスの設計には、例えば図８に示す様な、メッセージ・シーケンス・チャート（以下、「ＭＳＣ」という）という設計書が使用されることが多い。
【０００４】
図８はＭＳＣの一例を示す図であり、このＭＳＣでは、車両の自動変速装置の電子制御において、出力軸回転数に応じて自動変速機の変速段を１速から２速にシフトアップ（１−２変速）させる際に各オブジェクトが出力すべきメッセージが規定されている。このＭＳＣにおいて、「変速出力マネージャ」は、トルクコンバータの出力軸回転数に応じて変速段を決定するオブジェクトであり、「シーケンスマネージャ」は、例えば「現在変速中か否か」等の各種条件に基づいて変速可能か否かを判断するオブジェクトである。そして、「制御状態コントローラ」は、自動変速機内にある複数のソレノイドバルブの内、どのバルブをどのタイミングで開閉するかを決定するオブジェクトであり、「１−２変速制御部品」は、１−２変速に必要なソレノイドバルブの駆動制御を行うオブジェクトである。なお、「オブジェクトが…する。」や「オブジェクトは…する。」といったオブジェクトを主語とした動作表現は、実際には、コンピュータのＣＰＵがオブジェクトに従って動作する（換言すれば、ＣＰＵがオブジェクトとして規定された処理を実行する）ことで実現される機能手段が、上記「…」の動作を行うことを意味する。
【０００５】
そして、図８のＭＳＣでは、「変速出力マネージャ」は「出力軸回転数＝２００〜５００ｒｐｍ」と判断すると、「シーケンスマネージャ」に対して、１−２変速が可能か否かの判断処理を要求するメッセージ（１−２変速出力）を送ること、「シーケンスマネージャ」は、変速可能か否かの判断を行い、その結果、変速可能であるとき、変速種別を示す変速パターンＩＤを、１−２変速に当たる「０」に変更して、「制御状態コントローラ」に、１−２変速制御の処理を要求するメッセージ（１−２変速制御開始要求）を送ること、及び「制御状態コントローラ」は、ソレノイドバルプを決定し、決定されたソレノイドバルブを駆動するオブジェクトとしての「１−２変速制御部品」に通電処理を要求するメッセージ（通電開始要求）を送ることが、設計されている。
【０００６】
【発明が解決しようとする課題】
ところで、上記の様なＭＳＣに規定された結合を実現することを目標としてオブジェクトが作成（即ち、ソースプログラムが記述）されるが、その後、オブジェクト間の結合が設計通りに行われ、ソフトウェア全体として設計通りの機能が満足されるかどうかについての検査（所謂結合検査）が必要である。こうした結合検査は、ソースプログラムとＭＳＣを目で見て比較することにより実施することも考えられる。即ちＭＳＣに記述された順番通りに、メッセージ出力が行われているかどうかをソースプログラムを読んで追っていくことにより、両者が比較される。
【０００７】
しかし、それだけでは、実際に、その新たに開発したソフトウェアによってハードウェアを動作させた際に、ＭＳＣで規定されている機能・動作が実現されるかどうかを確かめることはできない。また、単に処理の実行順序を追うだけでは、上述の「出力軸回転数」や「変速パターンＩＤ」といった、マイクロコンピュータ内で扱われる処理データ（制御データ）についての所定条件（即ち、「出力軸回転数が２００ｒｐｍ以上５００ｒｐｍ以下」、「変速パターンＩＤが０」）が満たされた上で、「１−２変速出力」、「１−２変速制御開始要求」といったメッセージが出力されているかどうかを確かめることはできない。
【０００８】
例えば図８のＭＳＣにおいては、変速出力マネージャは「出力軸回転数が２００〜５００ｒｐｍ」であると判断すると、シーケンスマネージャに対して１−２変速を要求するメッセージを出力することが規定されているが、オブジェクト間におけるメッセージの流れのみを検査したのでは、実際の出力軸回転数が１０００ｒｐｍであるにも拘わらずメッセージが出力（発行）されてはいないか、などを検査することはできない。即ち、実際の出力軸回転数が１０００ｒｐｍであるにも拘わらず、１−２変速を要求するメッセージが出力されていたとしても、その誤りを発見することができない。
【０００９】
なお、こうした問題は、オブジェクト指向のシステム設計におけるソフトウェア開発に限られるものではなく、複数のソフトウェア部品の結合により新たなソフトウェアを作成する場合であれば、同様な問題が生ずる。
本発明は、上記問題に鑑みなされたものであり、複数のソフトウェア部品を結合して構成されるソフトウェアの結合検査を効率良く行うことができるソフトウェア結合検査装置を提供することを目的とする。
【００１０】
【課題を解決するための手段及び発明の効果】
上記課題を解決するためになされた本発明（請求項１記載）のソフトウェア結合検査装置においては、設計書情報読取手段が、画像表示データから、設計書上の文字及び図形の位置を検出し、その検出結果に基づいて、ソフトウェア部品間における処理依頼およびその処理データを設計書情報として読み取り、実行履歴情報読取手段が、設計書に基づき作成されたソフトウェアの実行結果から、該実行結果に格納されているソフトウェア部品間における処理依頼およびその出力条件としての処理データを実行履歴情報として時系列順に読み取り、比較手段が実行履歴情報と設計書情報とを比較して、その両情報の一致・不一致を判定し、出力手段が、その判定結果を当該ソフトウェア結合検査装置外部に出力する。
【００１１】
即ち、請求項１のソフトウェア結合検査装置においては、設計書の画像表示データから設計書情報（即ち設計書中に規定されているソフトウェア部品間における処理依頼およびその出力条件としての処理データ）を読み取り、一方、実行結果から実行履歴情報（即ち、ソフトウェア部品間における処理依頼およびその出力条件としての処理データ）を読み取り、その設計書情報と実行履歴情報とを比較し、両情報の一致・不一致を判定して、その判定結果を出力する。なお、両情報の比較とは、設計書情報に規定されている処理依頼と実行履歴情報内の処理依頼との比較、および、設計書情報に規定されている処理データと実行履歴情報内の処理データとの比較により図られる。
【００１２】
そのため、請求項１記載のソフトウェア結合検査装置によれば、複数のソフトウェア部品を結合して作成したソフトウェアによって設計書通りの処理動作が実現されているか否かを容易に判断することができる。しかも、両情報の比較は、ソフトウェア部品間における処理依頼だけでなく、処理依頼の出力条件についても行うので、正しい条件で他のソフトウェア部品に処理依頼されているかなど、ソフトウェア部品の結合の良否判断をより確実に行うことができる。なお、設計書情報と実行履歴情報とが「一致している」とは、設計諸情報の内容（処理依頼および処理データ）に実行履歴情報の内容（処理依頼および処理データ）が矛盾していないことであり、例えば、設計諸情報の処理データがある数値範囲で表されている場合に、実行履歴情報の処理データがその数値範囲にあることを意味する。
【００１３】
さて、出力手段が出力する判定結果としては、単に、一致か不一致かを出力するようにしても良いが、それのみでは、設計書にて規定されている内容の内、どの部分が現実と異なっているかを特定するのは容易でない。
そこで請求項２記載の様に、出力手段を、比較判定手段が実行履歴情報と設計書情報とが不一致であると判定すると、その実行履歴情報の内、設計書情報と不一致の箇所を出力する様に構成すると良い。この様に構成された請求項２記載のソフトウェア結合検査装置によれば、実行履歴情報の内、設計書情報と一致しない部分が出力されることから、新規のソフトウェアの内の修正すべき個所を特定し易くなるので好ましい。
【００１４】
ところで、検査対象のソフトウェアが、所定の制御対象物を制御するためのものである場合、設計書に規定される処理データは、その制御対象物を制御するための物理量で記述される一方、ソフトウェアが搭載されるマイクロコンピュータにおいては、物理量がＡ／Ｄ変換された制御データ（デジタル値）に基づいた処理が行われる。即ち、ソフトウェアが扱う処理データとして、物理量がＡ／Ｄ変換された制御データが扱われる。そのため、Ａ／Ｄ変換における分解能を考慮しなければ、設計書情報と実行履歴情報とを比較することができない。
【００１５】
そこで、検査対象のソフトウェアが、所定の制御対象物を制御するための物理量をＡ／Ｄ変換して得られる制御データに基づき、その制御対象物を制御するためのものであって、設計書には、処理データとして、その制御対象物を制御するための物理量が記述されている場合には、請求項３記載の様に、請求項１又は２に記載のソフトウェア結合検査装置において、Ａ／Ｄ変換により得られる制御データ毎に、そのＡ／Ｄ変換の際の分解能を表す分解能情報を記憶した分解能情報記憶手段を設け、実行履歴情報読取手段を、実行結果格納手段に記憶された実行結果から、分解能情報に基づき、処理データとしての制御データを読み取るよう構成するとよい。この様に構成された請求項３記載のソフトウェア結合検査装置によれば、実行結果格納手段に格納された実行結果から、制御データを実際の物理量として読み取ることから、実行履歴情報と設計書情報との比較が可能となる。
【００１６】
また、制御データのデータ型を符号付き（即ち、正数および負数を表現可能なデータ型）として扱うか、否かは、制御データ毎によって異なるのが普通であり、そして、そのデータ長も制御データ毎によって異なるのが普通である。これらを考慮しなければ、実行結果格納手段に記憶された実行結果から、制御データを正確に読み取ることはできない。
【００１７】
そこで、請求項４記載の様に、制御データ毎に、そのデータ型が符号付きか否かを表す符号情報を記憶した符号情報記憶手段を設け、実行履歴情報読取手段を、実行結果格納手段に記憶された実行結果から、符号情報に基づき制御データを読み取るよう構成すると良い。この様に構成された請求項４記載のソフトウェア結合検査装置によれば、制御データ毎に、符号付きか否かが異なる場合であっても、実行結果格納手段に記憶された実行結果から、正確な制御データの読み取りが可能となる。
【００１８】
そして、請求項５記載の様に、制御データ毎に、そのデータ長を表すデータ長情報を記憶したデータ長情報記憶手段を設け、実行履歴情報読取手段を、実行結果格納手段に記憶された実行結果から、データ長情報に基づき制御データを読み取るよう構成すると良い。この様に構成された請求項５記載のソフトウェア結合検査装置によれば、制御データ毎に、そのデータ長が異なる場合であっても、実行結果格納手段に記憶された実行結果から、正確な制御データの読み取りが可能となる。
【００１９】
【発明の実施の形態】
以下、本発明の一実施例として、車載電子制御装置（ＥＣＵ）に搭載するソフトウェアの開発において使用されるソフトウェア結合検査装置について、図面と共に説明する。
【００２０】
図１は、実施例のソフトウェア結合検査装置２の全体構成を表す説明図であり、図に示す様に、ソフトウェア結合検査装置２は、各種演算処理を行うＣＰＵの他、メモリ装置（例えばＲＯＭ、ＲＡＭ）等を備えたコンピュータ４と、このコンピュータ４に接続され、検査対象の設計書の整理番号（シナリオ番号）等の各種の情報を入力するための入力装置（キーボード６、マウス８等）と、このコンピュータ４に接続され画面表示可能な表示装置１０とを備えている。また、コンピュータ４には、画像表示データ格納サーバ１４およびロギングデータ格納サーバ１６が、通信線を介して接続されている。なお、画像表示データ格納サーバ１４が、請求項の「画像表示データ格納手段」に相当し、ロギングデータ格納サーバ１６が請求項の「実行結果格納手段」に相当する。また、表示装置１０が請求項の「出力手段」に相当する。
【００２１】
画像表示データ格納サーバ１４には、開発ターゲット（即ち本実施例では、ＥＣＵ）に要求される仕様をＭＳＣとして記述した多数の設計書の画像表示データが格納されている。この画像表示データは、文字データおよび図形データから構成されたものであり、その一例を図２（ａ）を用いて説明する。
【００２２】
図２（ａ）に例示するＭＳＣは、４つのオブジェクトＯｂｊ１，Ｏｂｊ２，Ｏｂｊ３，Ｏｂｊ４の結合を示したものである。ＭＳＣでは、各オブジェクトは「オブジェクト名」を示す文字及びその文字の下方に配置される縦線（以下「生存線」という）として示され、一のオブジェクトから他のオブジェクトへのメッセージ（処理依頼）は生存線の間に引かれた矢印として表示される。また、上から下に向かう方向は時間の経過を示しており、上方に表示されたメッセージから順に出力が行われることを示している。即ち、図２（ａ）に示すＭＳＣにおいては、まず最初にオブジェクトＯｂｊ１がＯｂｊ２へメッセージＭＳＧ１を出力し、次にオブジェクトＯｂｊ２がＯｂｊ３へメッセージＭＳＧ２を出力し、続いてオブジェクトＯｂｊ３がＯｂｊ４へメッセージＭＳＧ３を出力し、そしてオブジェクトＯｂｊ４がＯｂｊ３へメッセージＭＳＧ４を出力し、最後にオブジェクトＯｂｊ３がＯｂｊ１へメッセージＭＳＧ５を出力すべきことが示されている。
【００２３】
各オブジェクトは、メッセージを受けるとそれに対応した処理を行い、必要に応じて他のオブジェクトに対しメッセージを出力するが、メッセージの出力に当たって所定の条件が満たされる必要がある場合には、その満たされるべき条件（例えば、オブジェクトにより行われる処理で扱われる変数（処理データ）が、予め設定された値或いは所定範囲の値であること等）が、そのメッセージを示す矢印よりも上側であって生存線に重なるよう配置された枠の中に記述される。即ち、図２（ａ）に示すＭＳＣにおいては、処理データ「ｄａｔａ１」が「ＸＸＸ（数値或いは数値範囲）」という条件（即ち請求項の処理データ）を満たしている場合にのみ、オブジェクト０ｂｊ１がオブジェクト０ｂｊ２に対してメッセージＭＳＧ１を出力し、また、メッセージＭＳＧ１を受けたオブジェクト２は、処理データ「ｄａｔａ２」が「ＹＹＹ（数値或いは数値範囲）」という条件を満たしている場合にのみ、オブジェクト０ｂｊ３に対してメッセージＭＳＧ２を出力すべきことが示されている。なお、図２（ａ）に示す様に、各画像表示データには、個々の設計書を識別するためのシナリオ番号（ＺＺＺＺ）が付されている。
【００２４】
図１に戻り、一方、ロギングデータ格納サーバ１６にはプログラムの実行結果を示すデータが格納されている。この実行結果を示すデータは、プログラム設計書に従って作成されたソースプログラムＳが、実行可能なロードモジュールとして開発ターゲットであるＥＣＵ１８にて実行された途中経過を含む実行結果である。ＥＣＵ１８には、ＥＣＵ１８のマイクロプロセッサにより本来行われるべき動作を模擬的に実現するインサーキットエミュレー夕（ＩＣＥ）１８ａが接続されており、ロードモジュールに従って行われたＥＣＵ１８の動作結果はＩＣＥ１８ａにより抽出され、ロギングデータ格納サーバ１６に格納されている。
【００２５】
ソフトウェアの結合検査は、上記のように構成されたソフトウェア結合検査装置２を使用して、図３に示す検査処理により行われる。検査処理はソフトウェア結合検査装置２に対し、予め定められた命令をキーボード６から入力することにより起動される処理であり、起動されると、まず設計書情報の取込が行われる（Ｓ１００）。設計書情報の取込は、図４に示す設計書情報取込処理により行われるものであり、この設計書情報取込処理では、図２（ａ）に示す様なＭＳＣを構成する図形や文字を認識し、図面の左上部を基準点（原点）とした、それら図形や文字の位置を検出することにより、オブジェクト間におけるメッセージ出力の順序やメッセージ出力条件としての処理データ条件を読み取る。なお、本実施例のソフトウェア結合検査装置２においては、横方向にｘ軸、縦方向にｙ軸をとり、ｘｙ座標平面における図形や文字の位置が検出される。
【００２６】
図４に示す様に、設計書情報取込処理が起動されると、まずステップ（以下「ステップ」を「Ｓ」で示す）１０２にて、シナリオ番号を検出する。シナリオ番号を配置すべき位置は予め設定されており、その設定された位置に配置された文字を読み取ることによりシナリオ番号の取り込みが行われる。シナリオ番号を検出した後、Ｓ１０４では、シナリオ番号よりも下方であって、ｙ軸方向の予め設定された所定範囲をスキャンすることによって、その所定範囲内にある文字を認識し、その座標を取り込む。そしてＳ１０６では、Ｓ１０４にて検出された文字を読み取ることによりオブジェクト名を取り込み、Ｓ１０８では、その読み取った文字（即ちオブジェクト名）の存在する範囲（ｘ軸方向の範囲）にある直線を、生存線として認識し、その位置（ｘ座標）を取り込む。
【００２７】
そして、Ｓ１１０では、ｙ軸方向の上記所定範囲に、その他にもオブジェクト名を示す文字がないかどうかを判断し、他にもある場合には（Ｓ１１０：ＮＯ）、Ｓ１０４に戻り、上記Ｓ１０４〜Ｓ１０８の処理を再び行う。つまり、Ｓ１０４〜Ｓ１０８の処理の繰り返しにより、当該ＭＳＣにて記述されているオブジェクトの名称（即ちオブジェクト名）及びそのオブジェクトに対応する生存線の位置（ｘ座標）が検出されることとなり、例えば図２（ａ）に示すＭＳＣにおいては、「０ｂｊ１」、「０ｂｊ２」、「０ｂｊ３」及び「０ｂｊ４」というオブジェクト名とそれらに対応する生存線の位置が検出されることとなる。その後、Ｓ１１０において、ｙ軸方向の上記所定範囲には、他にオブジェクト名を示す文字がない（ＹＥＳ）と判断されると、Ｓ１１２に移行する。
【００２８】
Ｓ１１２では、ｙ軸方向の上記所定範囲よりも更に下方に向かって（即ち時系列順に）スキャンすることにより、メッセージ出力条件としての処理データの条件を示した文字或いはメッセージを示す文字（これらをアイテムという）を探す。そしてＳ１１２にてアイテムが検出されると、その検出されたアイテムがメッセージを示すものか否かを、その直下に矢印があるか否かにより判断する（Ｓ１１４）。即ち、アイテムの直下に矢印がある場合には、メッセージであると判断し（Ｓ１１４：ＹＥＳ）、そのアイテムをメッセージ名として検出し（Ｓ１１６）、更に矢印の始点及び終点の座標を読み込み、上記検出した生存線のｘ座標に基づき、メッセージの発行元のオブジェクト及び送り先のオブジェクトを特定してメモリ装置に格納する（Ｓ１１８）。
【００２９】
一方、Ｓ１１４においてメッセージでない（ＮＯ）と判断すると、Ｓ１２０に移行して、上記アイテムが処理データの条件を示すものか否かを、それが枠で囲まれているか否かにより判断する（Ｓ１２０）。アイテムが枠で囲まれている場合には、処理データの条件であると判断し（Ｓ１２０：ＹＥＳ）、その枠内に配置された文字の内、左辺の文字を処理データ名として検出し（Ｓ１２２）、右辺の文字を処理データが取るべき値或いは値の範囲として読み込む（Ｓ１２４）。
【００３０】
そして、Ｓ１１２にて検出されたアイテムが、メッセージでもなく処理データの条件でもないもの（例えばソフトウェア結合検査のオプション機能用のアイテム等）である場合（Ｓ１２０：ＮＯ）には、そのアイテムに対して予め設定されているシステム処理を行う（Ｓ１２６）。
【００３１】
こうしてＳ１１２で検出されたアイテムの種類に応じた処理が行われると、Ｓ１２８に移行し、更に下方に向かってスキャンすることにより他のアイテムがないかどうかを判断し、他にもある場合（Ｓ１２８：ＮＯ）にはＳ１１２に戻る。一方、他にアイテムがないと判断した場合には（Ｓ１２８：ＹＥＳ）、Ｓ１３０に移行する。Ｓ１３０では、上述の一連の処理にて検出されたメッセージや処理データに関するデータ（処理データ名、処理データ条件、メッセージ名、オブジェクト名等）を、検出したアイテムのｙ座標に基づき時系列順にソートしてメモリ装置に格納した後、当該設計書情報取込処理を終了する。なお、この設計書情報取込処理は、請求項の「設計書情報読取手段」の一部として機能する。
【００３２】
以上の様にして、設計書情報取込処理において、画像表示データ格納サーバ１４内の画像表示データが、設計書に規定されている処理データの条件やオブジェクト間におけるメッセージ出力の出力順序等を示す所定の形式に変換されたデータとしてメモリ装置に格納される。即ち、図２（ａ）に示すＭＳＣは、図２（ｂ）の様な設計書情報として、コンピュータ４のメモリ装置に格納されることとなる。 なお、処理データ名、メッセージ名、オブジェクト名には、夫々に対応するデータＩＤ、メッセージＩＤ、オブジェクトＩＤが、所定のテーブルにて定められている（このうち処理データ名とデータＩＤとの対応関係を規定している変換テーブルを図７に示す）。即ち、Ｓ１３０では、上記ソートが行われるほか、検出された処理データ名、メッセージ名、オブジェクト名は、夫々、データＩＤ、メッセージＩＤ、オブジェクトＩＤに変換された後、設計書情報として格納される。
【００３３】
図３に戻り説明を続ける。上述の様に設計書情報の取込を行った（Ｓ１００）後、次にロギングデータの取込を行う（Ｓ２００）。ロギングデータの取込は、ロギングデータ格納サーバ１６に格納された実行結果（ロギングデータ）を示すデータを読込み、上記の設計書情報と比較し易い形式のロギングデータに変換するものである。図５にロギングデータの概念図を示す。図５において、図５（ａ）が実際のロギングデータを示す図であるが、１６進で書かれたデータの羅列のため、この内容説明に合わせたものを、図５（ｂ）に示す。
【００３４】
図５（ｂ）に示す様に、ロギングデータは、プログラムの実行履歴（メッセージ出力や制御データ等）が時系列的に格納された、多数のブロック（８バイト）で構成されており、各ブロック毎に、そのブロックが、どういった情報を格納しているかを示すデータ種別（２バイト）が付されている。データ種別が「０１００」であるブロックには、発行元のオブジェクトＩＤ、送り先のオブジェクトＩＤおよびメッセージＩＤといったメッセージ出力に関する情報が格納されており、データ種別が「０２００」であるブロックには、データＩＤおよびデータ値といった制御データに関する情報が格納されている。なお、ロギングデータには、所定の物理量をＡ／Ｄ変換して得られる制御データだけでなく、制御データ以外の処理データが記録されているが、簡単の為、統一して「制御データ」ということとする。
【００３５】
さて、ＥＣＵ１８では多数のＭＳＣに基づいて作成されたソフトウェアプログラムが連続して実行され、そしてロギングデータは、それら一連の実行履歴が記録されたものであることから、メッセージ或いは制御データに関する情報を格納したブロックが、夫々、どのＭＳＣに対応する実行履歴であるかが示される必要がある。そのため、同一のＭＳＣに対応する一連のブロック群の前後には、先頭（スタート（００００））或いは最後尾（エンド（ＦＦ００））を示すデータ種別が付されたブロックが挿入されている。データ種別が「００００」である先頭のブロックには、対応するＭＳＣのシナリオ番号が格納されている。なお、Ｓ２００の処理は、請求項の「実行履歴読取手段」の一部として機能する。
【００３６】
この様なロギングデータの取込（Ｓ２００）が行われると、Ｓ１００にて設計書情報として取り込まれた設計書のシナリオ番号に基づいて、ロギングデータの内の検査対象が特定され（Ｓ３００）、図６に示す比較処理が起動される（Ｓ４００）。
【００３７】
この比較処理は、コンピュータ４に入力されたシナリオ番号に対応する設計書情報（図２（ｂ））およびロギングデータ（図５）とを１ブロックずつ時系列順に読み出し、互いに比較することにより、ロギングデータと設計書情報との一致、不一致を検出するものであり、起動されると、まずＳ４０２において、上記Ｓ３００で特定された検査対象の内のロギングデータの１ブロックを読込み、その１ブロックの最初の２バイトに格納されている「データ種別」に基づいて、制御データか否かを判別する（Ｓ４０２）。本実施例では、上述の様に「０１００」ならメッセージ、「０２００」なら制御データを示している。
【００３８】
そして、制御データと判断された場合（Ｓ４０２：ＹＥＳ）、「データ種別」に続く２バイトの領域に格納されている「データＩＤ」を読込み（Ｓ４０４）、コンピュータ４のメモリ装置内に予め格納されている変換テーブル（図７）を参照して、その検出したデータＩＤに対応する制御データのデータ長（データサイズ、size）を読み取ると共に（Ｓ４０６）、その制御データが符号付きか否か（符号有無、型）を読み取る（Ｓ４０８）。
【００３９】
ここで、「データサイズ」とは、全４バイトの制御データ用の領域の内、何バイトが、制御データの表現に使用されているかを示す情報である。例えば、Ｓ４０４にて、データＩＤとして「１０」が得られた場合（即ち出力軸回転数）には、制御データ用の領域（４バイト）の内、２バイトが制御データの表現に使用されていることが、図７の変換テーブルから分かる。尚、「データサイズ」が請求項の「データ長情報」に相当する。
【００４０】
また、「符号有無」とは、制御データが、負数を含むか或いは正数のみかを示すものである。制御データが１バイト長である場合、符号なしである正数型（ｕ）として定義されているときには、１０進法の「０」〜「２５５」を表すので、２進法の「１１１１１１１１」は「２５５」を示すが、符号付きである負数型（ｓ）として定義されている場合には、１０進法の「−１２８」〜「１２７」を表すので、同じ２進法の「１１１１１１１１」であっても１０進法の「−１」を示すことになる。よって、制御データの内容を正しく検出するためには、「符号有無」を確認する必要があるのである。なお、例えばＳ４０４にて、データＩＤが「１０」である場合には、図７の変換テーブルから、「符号あり（ｓ）」であることが分かる。尚、「符号有無」が請求項の「符号情報」に相当する。
【００４１】
Ｓ４０８の後、上記の「データサイズ」および「符号有無」を考慮して、「データＩＤ」に続く２バイトの領域に格納されている「データ値」を読み取ると共に、その「データＩＤ」に対応するＬＳＢ（１ビット当たりの分解能）を変換テーブルから求め、「データＩＤ」に続く２バイトの領域に格納されている「データ値」に乗算することにより、実際の制御データの値に換算する（Ｓ４１０）。即ち、ロギングデータとして記録されているデータ値には、実際の物理量がデジタル値（２進数）に変換された制御データの値であるものも含まれるので、そのままでは、設計書情報にて物理量にて規定されている処理データの条件と比較できない。そのため、ロギングデータとして記録されているデータ値に、ＬＳＢを掛けることにより設計書情報に物理量にて規定されている処理データと比較可能な値に変換するのである。尚、この「ＬＳＢ」が請求項の「分解能情報」に相当する。そして、変換テーブルが、請求項の「分解能情報記憶手段」、「符号情報記憶手段」および「データ長情報記憶手段」として機能する。
【００４２】
こうして、Ｓ４０４〜Ｓ４１０の処理実行により、制御データを、設計書情報と比較できるようなデータとして読み取ると、次に、１ブロック分の設計書情報を読み込み、その１ブロック分の設計書情報とロギングデータとを（即ち、データＩＤおよびデータ値について）比較する（Ｓ４１２）。
【００４３】
そして、この比較（Ｓ４１４）の結果、設計書情報とロギングデータが一致しているか否かを判断し（Ｓ４１８）、両者（設計書情報とロギングデータ）が不一致の場合には（Ｓ４１８：ＮＯ）、当該ブロックのロギングデータ（データＩＤおよびデータ値）を、それが先頭ブロックから何ブロック目であるかを示すブロック番号等と共に、メモリ装置に保持した後（Ｓ４２０）、Ｓ４２２に移行する。これは、後述する様に、不一致箇所のロギングデータがどの様な値（ＮＧデータ）であったかを表示装置１０に表示させるために保持するものである。一方、設計書情報とロギングデータとが一致している場合には（Ｓ４１８：ＹＥＳ）、Ｓ４２２にそのまま移行する。
【００４４】
ところで、Ｓ４０２にて読み込んだ、ロギングデータの１ブロックが制御データを格納するものでない場合（即ちメッセージである場合）には（Ｓ４０２：ＮＯ）、設計書情報の１ブロック分を読み込み（Ｓ４１５）、その１ブロック分の設計書情報とロギングデータとを（即ち、発行元のオブジェクトＩＤ、送り先のオブジェクトＩＤおよびメッセージＩＤについて）比較する（Ｓ４１６）。
【００４５】
そして、この比較（Ｓ４１６）の結果、設計書情報とロギングデータが一致しているか否かを判断し（Ｓ４１８）、両者（設計書情報とロギングデータ）が不一致の場合には（Ｓ４１８：ＮＯ）、当該ブロックのロギングデータ（発行元のオブジェクトＩＤ、送り先のオブジェクトＩＤおよびメッセージＩＤ）を、それが先頭ブロックから何ブロック目であるかを示すブロック番号等と共に、メモリ装置に保持した後（Ｓ４２０）、Ｓ４２２に移行する。一方、設計書情報とロギングデータとが一致している場合には（Ｓ４１８：ＹＥＳ）、Ｓ４２２にそのまま移行する。
【００４６】
Ｓ４２２では、上記Ｓ４０２にて読み込んだ１ブロックのロギングデータに続いて、別の１ブロックを読込み、そのブロックに付されたデータ種別が、「エンド」であるか否か（本実施例では、データ種別が「ＦＦ００」か否か）を判断し、「エンド」でなければ（Ｓ４２２：ＮＯ）、Ｓ４０２に戻って上記の処理を再び行うが、「エンド」であれば（Ｓ４２２：ＹＥＳ）、当該比較処理を終了する。 つまり、比較処理では、Ｓ３００で特定されたロギングデータの全ブロックについて、対応する設計書情報と比較し、不一致の箇所があれば、その部分のロギングデータを保持するのである。なお、上述のＳ４０４〜Ｓ４１０の処理が、請求項の「実行履歴情報読取手段」の一部として機能し、Ｓ４１２およびＳ４１５の処理が、請求項の「設計書情報読取手段」の一部として機能し、Ｓ４１４、Ｓ４１６およびＳ４１８の処理が、請求項の「比較判定手段」として機能する。
【００４７】
図３に戻り、Ｓ４００の比較処理の後、Ｓ５００に移行し、比較処理による比較結果が表示装置１０に画面表示される。即ち、表示装置１０には、設計書情報に基づいてＭＳＣが描かれ、比較結果が全て一致する場合（即ち、ＮＧデータがない場合）には“比較ＯＫ”と表示され、不一致部分がある場合には、“比較ＮＧ”という表示が行われると共に、上記Ｓ４２０にてＮＧデータとして格納されたロギングデータに基づいて、不一致の箇所が強調すべく色分けして表示される。その結果、設計書（即ちＭＳＣ）通りに、ソフトウェア部品の結合がなされていない場合には、直ちに問題箇所が発見される。
【００４８】
なお、Ｓ５００において設計書情報やロギングデータに基づいてＭＳＣが描かれる際には、データＩＤと制御データ名およびその制御データが所属するオブジェクト名との対応関係が規定された変換テーブル（図７）や、オブジェクトＩＤとオブジェクト名との対応関係やメッセージＩＤとメッセージ名との対応関係が規定されたテーブル（図示せず）が参照される。
【００４９】
以上の様に構成された動作する本実施例のソフトウェア結合検査装置によれば、以下の効果を奏する。（１）設計書の画像表示データから設計書情報を読み取り、一方、ＥＣＵ１８における実行結果からロギングデータを読み取り、その設計書情報とロギングデータとを比較し、両情報の一致・不一致を判定して、その判定結果を出力する。その結果、複数のソフトウェア部品を結合して作成したソフトウェアにおいて設計書通りの処理動作が実現されているか否かを容易に判断することができる。しかも、両情報の比較は、ソフトウェア部品間におけるメッセージの出力履歴（即ち処理依頼）だけでなく、メッセージの出力条件である制御データの履歴（即ち処理依頼の出力条件）についても行うので、ソフトウェア部品の結合の良否判断をより確実に行うことができる。
【００５０】
（２）ロギングデータと設計書情報とが不一致である場合には、そのロギングデータの内、設計書情報と不一致の箇所を出力することから、新規のソフトウェアの内の修正すべき個所を特定し易くなる。即ち、不一致箇所を表示することで、誤り箇所を容易に特定できプログラミングのミスを素早く修正できる。
【００５１】
（３）制御データ毎に、その制御データに対応するＡ／Ｄ変換の「ＬＳＢ」を記録した変換テーブル（図７）を備えており、そのテーブルに基づき、デジタル値で表現された制御データを読み取ることから、ロギングデータと設計書情報との比較が可能となる。
【００５２】
（４）制御データ毎に、そのデータ型が符号付きか否かを表す「符号有無」を記録した変換テーブル（図７）を備え、このテーブルに基づき制御データを読み取ることから、制御データ毎に符号付きか否かが異なる場合であっても、正確な制御データの読み取りが可能となる。
【００５３】
（５）制御データ毎に、そのデータ長を表す「データサイズ」を記録した変換テーブル（図７）を備え、このテーブルに基づき制御データを読み取ることから、制御データ毎にデータ長が異なる場合であっても、正確な制御データの読み取りが可能となる。
【００５４】
尚、本発明の実施の形態は、上記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り、種々の形態を探り得ることは言うまでもない。
例えば、上記実施例では、ＥＣＵ１８上にて、検査対象であるソフトウェアを機能させた実行結果を、設計書との比較に使用しているが、これに限られるものではなく、コンピュータ上でのシミュレーションにより実行結果を得たものを使用しても良い。
【００５５】
また、上記実施例では、比較結果をＭＳＣの形で表示装置１０に表示するものとして説明したが、これに限られるものでなく、例えばリスト形式にして表示するようにしても良い。また、表示装置１０に限らず、例えばプリンタにより文書として出力しても良い。
【図面の簡単な説明】
【図１】 本発明の一実施例としてのソフトウェア結合検査装置の構成を示す説明図である。
【図２】 画像表示データとしての設計書（ＭＳＣ）および設計書情報の内容を示す説明図である。
【図３】 検査処理を示すフローチャートである。
【図４】 設計書情報取込処理を示すフローチャートである。
【図５】 ロギングデータの内容を示す説明図である。
【図６】 比較処理を示すフローチャートである。
【図７】 変換テーブルを示す説明図である。
【図８】 メッセージ・シーケンス・チャートの一例を示す説明図である。
【符号の説明】
２…ソフトウェア結合検査装置、４…コンピュータ、１０…表示装置、１４…画像表示データ格納サーバ、１６…ロギングデータ格納サーバ、Ｓ…ソースプログラム。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a software combination inspection apparatus for performing a combination inspection of software constituted by combining a plurality of software components (software modules).
[0002]
[Prior art]
Conventionally, in software development in, for example, object-oriented system design, new software having a desired function has been developed by combining a plurality of software components (which are regarded as “objects” in object-oriented). ing. Note that object-oriented is a computer system modeled on the concept of working while paying attention to the operation target as if a human is acting. In object-oriented programming, program processing Think in units of An object is a software module that combines object-specific data and processing for handling the data.
[0003]
An object is joined by outputting a “processing request (message)” indicating that a specific process is to be executed from one object to another object. The specified process is performed. Therefore, in order to realize a desired function with new software to be created by combining objects, design the message output destination, output order, output conditions, etc. from each object (design message sequence). Is required. In designing a message sequence, a design document called a message sequence chart (hereinafter referred to as “MSC”) as shown in FIG. 8 is often used.
[0004]
FIG. 8 is a diagram showing an example of the MSC. In this MSC, in the electronic control of the automatic transmission device of the vehicle, the shift stage of the automatic transmission is shifted up from the first speed to the second speed according to the output shaft rotational speed (1 -2), a message to be output by each object is defined. In this MSC, the “shift output manager” is an object that determines the shift stage according to the output shaft rotational speed of the torque converter, and the “sequence manager” is set according to various conditions such as “whether or not currently shifting”. It is an object that determines whether or not a shift is possible based on this. The “control state controller” is an object that determines which valve is opened / closed at which timing among a plurality of solenoid valves in the automatic transmission, and “1-2 shift control component” is 1-2. It is an object that performs drive control of the solenoid valve necessary for gear shifting. It should be noted that the behavioral expression having the object as an object such as “object is ...” or “object is ...” actually operates according to the object of the CPU of the computer (in other words, the CPU is defined as the object). This means that the functional means realized by executing the above processing performs the operation “...
[0005]
In the MSC of FIG. 8, when the “shift output manager” determines that “output shaft speed = 200 to 500 rpm”, the “sequence manager” is requested to determine whether or not 1-2 shift is possible. The “sequence manager” determines whether or not the shift is possible. As a result, when the shift is possible, the shift pattern ID indicating the shift type is set to 1-2. It is changed to “0” corresponding to the shift, and a message (1-2 shift control start request) for requesting the 1-2 shift control process is sent to the “control state controller”, and the “control state controller” Determines the valve and sends a message (energization start request) requesting energization processing to the “1-2 shift control component” as the object that drives the determined solenoid valve. It has been designed.
[0006]
[Problems to be solved by the invention]
By the way, objects are created (that is, source programs are described) with the goal of realizing the coupling defined in the MSC as described above, but then the coupling between the objects is performed as designed, and the software as a whole An inspection (so-called joint inspection) is required as to whether the designed function is satisfied. Such a combination test may be performed by visually comparing the source program and the MSC. That is, the two are compared by reading the source program and following whether the message is being output in the order described in the MSC.
[0007]
However, that alone cannot actually confirm whether or not the functions and operations defined by the MSC are realized when the hardware is operated by the newly developed software. Further, simply following the execution order of the processing, a predetermined condition (that is, “output shaft” for processing data (control data) handled in the microcomputer, such as the “output shaft rotational speed” and “shift pattern ID” described above. Whether or not messages such as “1-2 shift output” and “1-2 shift control start request” are output after the rotation speed is 200 rpm to 500 rpm and “shift pattern ID is 0”) are satisfied. I can't confirm.
[0008]
For example, in the MSC of FIG. 8, when the shift output manager determines that “the output shaft rotational speed is 200 to 500 rpm”, it is specified that a message requesting 1-2 shift is output to the sequence manager. However, if only the message flow between the objects is inspected, it cannot be inspected whether a message is output (issued) even though the actual output shaft rotational speed is 1000 rpm. That is, even if the message for requesting the 1-2 shift is output even though the actual output shaft rotational speed is 1000 rpm, the error cannot be found.
[0009]
Note that such a problem is not limited to software development in object-oriented system design, and a similar problem occurs when new software is created by combining a plurality of software components.
The present invention has been made in view of the above problems, and an object of the present invention is to provide a software combination inspection apparatus capable of efficiently performing a combination inspection of software configured by combining a plurality of software components.
[0010]
[Means for Solving the Problems and Effects of the Invention]
In the software combination inspection apparatus of the present invention (claim 1) made to solve the above-mentioned problem, the design document information reading means detects the positions of characters and figures on the design document from the image display data, Based on the detection result, the processing request between the software components and the processing data T Reading as design document information, the execution history information reading means from the execution result of the software created based on the design document, Stored in the execution result Processing between software components Order And the processing data as the output condition are read as execution history information in chronological order, the comparison means compares the execution history information with the design document information to determine whether the both information match or not, and the output means The determination result is output outside the software combination inspection apparatus.
[0011]
That is, in the software combination inspection apparatus according to the first aspect, the design document information (that is, the processing request between the software parts specified in the design document and the processing data as the output condition thereof is obtained from the image display data of the design document. T) On the other hand, from the execution result, the execution history information (that is, the processing Order And the processing data as the output condition) are compared, the design document information is compared with the execution history information, the coincidence / mismatch of the both information is determined, and the determination result is output. Note that the comparison of both types of information refers to the processing request specified in the design document information and the processing request in the execution history information. Yuri Comparison and processing data specified in design document information And This is achieved by comparison with the processing data in the execution history information.
[0012]
Therefore, according to the software combination inspection apparatus of the first aspect, it is possible to easily determine whether or not the processing operation according to the design document is realized by software created by combining a plurality of software components. Moreover, the comparison of both types of information depends on the processing between software components. Depend In addition, since the processing request output conditions are also performed, it is possible to more reliably determine whether or not the software components are combined, such as whether processing requests are issued to other software components under the correct conditions. The design document information and the execution history information “match” means that the contents of the design information (processing request and processing data) T) The contents of the execution history information Order And processing data) are not inconsistent, for example Design information Processing data T When it is expressed in a certain numerical range, this means that the processing data of the execution history information is in that numerical range.
[0013]
Now, as the determination result output by the output means, it may be simply output whether it is coincidence or non-coincidence, but only that part of the contents defined in the design document is different from the actual one. It is not easy to identify whether
Therefore, as described in
[0014]
By the way, when the software to be inspected is for controlling a predetermined control object, the processing data specified in the design document is used. T On the other hand, in the microcomputer on which the software is mounted, processing based on control data (digital value) obtained by A / D converting the physical quantity is performed. That is, control data whose physical quantity is A / D converted is handled as processing data handled by software. Therefore, the design document information and the execution history information cannot be compared without taking the resolution in A / D conversion into consideration.
[0015]
Therefore, the software to be inspected is for controlling the control object based on the control data obtained by A / D converting the physical quantity for controlling the predetermined control object. The processing data And When the physical quantity for controlling the control object is described, the software combination inspection apparatus according to
[0016]
Also, whether or not the data type of control data is treated as signed (that is, a data type that can express positive and negative numbers) usually differs depending on the control data, and the data length is also controlled. It usually differs depending on the data. Unless these are taken into consideration, the control data cannot be read accurately from the execution result stored in the execution result storage means.
[0017]
Therefore, as described in
[0018]
Further, as described in claim 5, for each control data, there is provided data length information storage means for storing data length information indicating the data length, and the execution history information reading means is stored in the execution result storage means. From the result, the control data may be read based on the data length information. According to the software combination inspection device according to claim 5 configured in this way, even if the data length differs for each control data, accurate control can be performed from the execution result stored in the execution result storage means. Data can be read.
[0019]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, as one embodiment of the present invention, a software combination inspection device used in the development of software installed in an in-vehicle electronic control unit (ECU) will be described with reference to the drawings.
[0020]
FIG. 1 is an explanatory diagram showing the overall configuration of the software
[0021]
The image display
[0022]
The MSC illustrated in FIG. 2A shows a combination of four objects Obj1, Obj2, Obj3, Obj4. In the MSC, each object is indicated as a character indicating “object name” and a vertical line (hereinafter referred to as “life line”) arranged below the character, and a message (processing request) from one object to another object. Is displayed as an arrow drawn between the lifelines. Further, the direction from top to bottom indicates the passage of time, indicating that output is performed in order from the messages displayed above. That is, in the MSC shown in FIG. 2A, the object Obj1 first outputs the message MSG1 to Obj2, then the object Obj2 outputs the message MSG2 to Obj3, and then the object Obj3 sends the message MSG3 to Obj4. It is shown that the object Obj4 should output the message MSG4 to Obj3, and finally the object Obj3 should output the message MSG5 to Obj1.
[0023]
Each object performs processing corresponding to the message when it receives a message, and outputs a message to other objects as necessary. However, when a predetermined condition needs to be satisfied in outputting the message, that object is satisfied. The power condition (for example, that a variable (processing data) handled in processing performed by the object is a preset value or a value within a predetermined range) is above the arrow indicating the message and is a lifeline It is described in a frame arranged so as to overlap. That is, in the MSC shown in FIG. 2A, the processing data “data1” is “XXX (numerical value or numerical range)” (that is, the processing data of claims). T) Only when the object 0bj1 outputs the message MSG1 to the object 0bj2, and the
[0024]
Returning to FIG. 1, the logging
[0025]
The software combination inspection is performed by the inspection process shown in FIG. 3 using the software
[0026]
As shown in FIG. 4, when the design document information fetching process is started, a scenario number is first detected at step (hereinafter “step” is indicated by “S”) 102. The position where the scenario number is to be placed is set in advance, and the scenario number is captured by reading the character placed at the set position. After the scenario number is detected, in S104, a character within the predetermined range is recognized by scanning a predetermined range below the scenario number and in the y-axis direction, and the coordinates are captured. . In S106, the object name is acquired by reading the character detected in S104. In S108, a straight line in the range (the range in the x-axis direction) where the read character (that is, the object name) exists is represented as a lifeline. And the position (x coordinate) is taken in.
[0027]
In S110, it is determined whether there is any other character indicating the object name in the predetermined range in the y-axis direction. If there is another character (S110: NO), the process returns to S104, and the above-described S104- The process of S108 is performed again. That is, by repeating the processing of S104 to S108, the name of the object (that is, the object name) described in the MSC and the position of the lifeline (x coordinate) corresponding to the object are detected. In the MSC shown in 2 (a), the object names “0bj1”, “0bj2”, “0bj3”, and “0bj4” and the positions of the lifelines corresponding to them are detected. Thereafter, if it is determined in S110 that there is no other character indicating the object name in the predetermined range in the y-axis direction (YES), the process proceeds to S112.
[0028]
In S112, by scanning further downward (that is, in chronological order) from the predetermined range in the y-axis direction, characters indicating processing data conditions as message output conditions or characters indicating messages (these are item Search). When an item is detected in S112, it is determined whether or not the detected item indicates a message based on whether or not there is an arrow immediately below the item (S114). That is, if there is an arrow directly under the item, it is determined that the message is a message (S114: YES), the item is detected as a message name (S116), and the coordinates of the start point and end point of the arrow are read and the above detection is performed. Based on the x-coordinate of the lifeline, the message source object and the destination object are specified and stored in the memory device (S118).
[0029]
On the other hand, if it is determined that the message is not a message (NO) in S114, the process proceeds to S120, and it is determined whether or not the item indicates the condition of the processing data based on whether or not it is surrounded by a frame (S120). . If the item is surrounded by a frame, it is determined that the condition is the condition of the processing data (S120: YES), and the character on the left side of the characters arranged in the frame is detected as the processing data name (S122). ), The character on the right side is read as a value or a range of values to be taken by the processing data (S124).
[0030]
If the item detected in S112 is neither a message nor a processing data condition (for example, an item for an optional function of software combination inspection) (S120: NO), the item is Pre-set system processing is performed (S126).
[0031]
When processing according to the type of the item detected in S112 is performed in this way, the process proceeds to S128, and it is further determined by scanning downward that there is no other item (S128). : NO) returns to S112. On the other hand, when it is determined that there are no other items (S128: YES), the process proceeds to S130. In S130, the data (processing data name, processing data condition, message name, object name, etc.) related to the message and processing data detected in the above-described series of processing is sorted in chronological order based on the y-coordinate of the detected item. Then, the design document information fetching process is terminated. This design document information fetching process functions as a part of “design document information reading means” in the claims.
[0032]
As described above, in the design document information capturing process, the image display data in the image display
[0033]
Returning to FIG. 3, the description will be continued. After the design document information is fetched as described above (S100), logging data is fetched next (S200). The logging data is read by reading the data indicating the execution result (logging data) stored in the logging
[0034]
As shown in FIG. 5B, the logging data is composed of a number of blocks (8 bytes) in which the program execution history (message output, control data, etc.) is stored in time series. A data type (2 bytes) indicating what information is stored in each block is attached to each block. The block whose data type is “0100” stores information related to message output such as the object ID of the issuer, the object ID of the destination, and the message ID. The block whose data type is “0200” contains the data ID. In addition, information on control data such as data values is stored. The logging data includes not only control data obtained by A / D conversion of a predetermined physical quantity but also processing data other than the control data. For simplicity, the data is collectively referred to as “control data”. I will do it.
[0035]
In the
[0036]
When such logging data is fetched (S200), the inspection target in the logging data is specified based on the scenario number of the design document fetched as design document information in S100 (S300). 6 is started (S400).
[0037]
In this comparison process, the design document information (FIG. 2B) and the logging data (FIG. 5) corresponding to the scenario number input to the
[0038]
If the control data is determined (S402: YES), the “data ID” stored in the 2-byte area following the “data type” is read (S404) and stored in the memory device of the
[0039]
Here, the “data size” is information indicating how many bytes are used for expressing control data in the control data area of all 4 bytes. For example, when “10” is obtained as the data ID in S404 (that is, the output shaft rotation speed), 2 bytes are used for the control data expression in the control data area (4 bytes). It can be seen from the conversion table in FIG. The “data size” corresponds to “data length information” in the claims.
[0040]
The “sign presence / absence” indicates whether the control data includes a negative number or only a positive number. If the control data is 1 byte long and is defined as an unsigned positive number type (u), it represents the decimal numbers “0” to “255”, so the binary number “11111111” is “255” is shown, but when it is defined as a negative number type (s) with a sign, it represents “−128” to “127” in decimal notation, and therefore “11111111” in the same binary notation. Even if it exists, it will show decimal "-1". Therefore, in order to correctly detect the contents of the control data, it is necessary to confirm “code presence / absence”. For example, in S404, when the data ID is “10”, it can be seen from the conversion table of FIG. 7 that “there is a code (s)”. “Code presence / absence” corresponds to “code information” in the claims.
[0041]
After S408, in consideration of the above "data size" and "presence / absence of code", the "data value" stored in the 2-byte area following "data ID" is read and the "data ID" is supported LSB (resolution per bit) is calculated from the conversion table, and is multiplied by the “data value” stored in the 2-byte area following the “data ID”, thereby converting it to the actual control data value ( S410). In other words, the data value recorded as logging data includes the value of the control data obtained by converting the actual physical quantity into a digital value (binary number). Cannot be compared with the processing data conditions specified in the For this reason, the data value recorded as the logging data is multiplied by LSB to convert it into a value that can be compared with the processing data defined by the physical quantity in the design document information. The “LSB” corresponds to “resolution information” in the claims. The conversion table functions as “resolution information storage means”, “code information storage means”, and “data length information storage means” in the claims.
[0042]
Thus, when the control data is read as data that can be compared with the design document information by executing the processing of S404 to S410, next, the design document information for one block is read, and the design document information and logging for that one block. The data is compared (that is, regarding the data ID and the data value) (S412).
[0043]
Then, as a result of this comparison (S414), it is determined whether the design document information and the logging data match (S418). If the two (design document information and logging data) do not match (S418: NO). After the logging data (data ID and data value) of the block is held in the memory device together with the block number indicating the number of blocks from the first block (S420), the process proceeds to S422. As will be described later, this holds what value (NG data) the logging data of the non-matching part is displayed on the
[0044]
By the way, when one block of logging data read in S402 does not store control data (that is, a message) (S402: NO), one block of design document information is read (S415), The design document information for one block and the logging data are compared (that is, the object ID of the issuer, the object ID of the destination, and the message ID) (S416).
[0045]
Then, as a result of this comparison (S416), it is determined whether the design document information and the logging data match (S418). If the two (design document information and logging data) do not match (S418: NO). After the logging data (issuer object ID, destination object ID, and message ID) of the block is stored in the memory device together with a block number indicating the number of blocks from the top block, etc. (S420) , The process proceeds to S422. On the other hand, if the design document information matches the logging data (S418: YES), the process proceeds to S422 as it is.
[0046]
In S422, following one block of logging data read in S402, another block is read, and whether or not the data type attached to the block is “end” (in this embodiment, data If the type is “FF00” and not “End” (S422: NO), the process returns to S402 and the above process is performed again. If “End” (S422: YES), The comparison process ends. That is, in the comparison process, all the blocks of the logging data specified in S300 are compared with the corresponding design document information, and if there is a mismatch, the logging data of that part is held. Note that the processing of S404 to S410 described above functions as part of the “execution history information reading unit” in claims, and the processing of S412 and S415 functions as part of the “design document information reading unit” in claims. The processes of S414, S416, and S418 function as “comparison determination means” in the claims.
[0047]
Returning to FIG. 3, after the comparison process of S <b> 400, the process proceeds to S <b> 500, and the comparison result of the comparison process is displayed on the screen of the
[0048]
When the MSC is drawn based on the design document information and logging data in S500, a conversion table that defines the correspondence between the data ID, the control data name, and the object name to which the control data belongs (FIG. 7). Alternatively, a table (not shown) in which the correspondence between the object ID and the object name and the correspondence between the message ID and the message name are defined is referred to.
[0049]
According to the software combination inspection apparatus of the present embodiment configured as described above, the following effects can be obtained. (1) The design document information is read from the image display data of the design document, while the logging data is read from the execution result in the
[0050]
(2) If the logging data does not match the design document information, the part of the logging data that does not match the design document information is output. It becomes easy. That is, by displaying the inconsistent portion, the erroneous portion can be easily identified and the programming mistake can be corrected quickly.
[0051]
(3) It has a conversion table (FIG. 7) in which “LSB” of A / D conversion corresponding to the control data is recorded for each control data. Based on the table, the control data expressed by digital values is provided. Since reading is performed, the logging data and the design document information can be compared.
[0052]
(4) Each control data is provided with a conversion table (FIG. 7) in which “data presence / absence” indicating whether or not the data type is signed is provided, and the control data is read based on this table. Even when the sign is different, accurate control data can be read.
[0053]
(5) Each control data has a conversion table (FIG. 7) in which the “data size” representing the data length is recorded, and the control data is read based on this table. Even if it is, accurate control data can be read.
[0054]
Needless to say, the embodiments of the present invention are not limited to the above-described embodiments, and various forms can be searched as long as they belong to the technical scope of the present invention.
For example, in the above embodiment, the execution result obtained by causing the software to be inspected to function on the
[0055]
In the above-described embodiment, the comparison result is described as being displayed on the
[Brief description of the drawings]
FIG. 1 is an explanatory diagram showing a configuration of a software combination inspection apparatus as an embodiment of the present invention.
FIG. 2 is an explanatory diagram showing the contents of a design document (MSC) as image display data and design document information.
FIG. 3 is a flowchart showing an inspection process.
FIG. 4 is a flowchart showing design document information fetch processing.
FIG. 5 is an explanatory diagram showing the contents of logging data.
FIG. 6 is a flowchart showing a comparison process.
FIG. 7 is an explanatory diagram showing a conversion table.
FIG. 8 is an explanatory diagram showing an example of a message sequence chart.
[Explanation of symbols]
2 ... software combination inspection device, 4 ... computer, 10 ... display device, 14 ... image display data storage server, 16 ... logging data storage server, S ... source program.
Claims (5)
ソフトウェア部品間における処理依頼およびその出力条件としての処理データが文字および図形により時系列的に規定された設計書の画像表示データを格納する画像表示データ格納手段と、
該画像表示データ格納手段に記憶された画像表示データから、前記設計書上の文字及び図形の位置を検出し、該検出結果に基づいて、ソフトウェア部品間における処理依頼およびその処理データを設計書情報として読み取る設計書情報読取手段と、
前記設計書に基づき作成された前記ソフトウェアの実行結果を格納する実行結果格納手段と、
該実行結果格納手段に格納された実行結果から、該実行結果に格納されているソフトウェア部品間における処理依頼およびその出力条件としての処理データを実行履歴情報として時系列順に読み取る実行履歴情報読取手段と、
該実行履歴情報読取手段にて読み取られた実行履歴情報を、前記設計書情報読取手段にて読み取られた設計書情報と比較し、該両情報の一致・不一致を判定する比較判定手段と、
該比較判定による判定結果を、当該ソフトウェア結合検査装置外部に出力する出力手段と、
を備えたことを特徴とするソフトウェア結合検査装置。A software combination inspection device configured to inspect software that is configured by combining a plurality of software parts and that functions by sending and receiving processing requests between the plurality of software,
And image display data storing means for processing data in a processing request and its output condition between software components for storing image display data for time series defined design document by the character and graphics,
The image display data stored in the image display data storing means, detects a position of the character and graphics on the design document, based on the detection result, design document processing request and the processing data between software components Design document information reading means for reading as information;
Execution result storage means for storing the execution result of the software created based on the design document;
From the execution result stored in the execution result storage unit, read the execution history information read in chronological order processing data as a processing Yi Lai AND ITS output condition among the software component stored in said execution result as execution history information Means,
A comparison determination unit that compares the execution history information read by the execution history information reading unit with the design document information read by the design document information reading unit, and determines whether or not the information matches.
An output means for outputting a determination result by the comparison determination to the outside of the software combination inspection device;
A software combination inspection apparatus comprising:
前記出力手段は、前記比較判定手段が前記実行履歴情報と前記設計書情報とが不一致であると判定すると、該実行履歴情報の内、前記設計書情報と不一致の箇所を出力することを特徴とするソフトウェア結合検査装置。The software combination inspection apparatus according to claim 1,
The output unit, when the comparison determination unit determines that the execution history information and the design document information do not match, outputs a portion of the execution history information that does not match the design document information. Software integration inspection device.
検査対象のソフトウェアは、所定の制御対象物を制御するための物理量をＡ／Ｄ変換して得られる制御データに基づき、該制御対象物を制御するためのものであって、
前記設計書には、前記処理データとして、前記制御対象物を制御するための物理量が記述されており、
前記Ａ／Ｄ変換により得られる制御データ毎に、そのＡ／Ｄ変換の際の分解能を表す分解能情報を記憶した分解能情報記憶手段を備え、
前記実行履歴情報読取手段は、前記実行結果格納手段に記憶された実行結果から、前記分解能情報に基づき、前記処理データとして、前記制御データを読み取ることを特徴とするソフトウェア結合検査装置。In the software combination inspection apparatus according to claim 1 or 2,
The software to be inspected is for controlling the control object based on control data obtained by A / D converting a physical quantity for controlling the predetermined control object,
Wherein the design document, and with the processing data, the physical quantity for controlling the controlled object is described,
For each control data obtained by the A / D conversion, there is provided resolution information storage means for storing resolution information indicating the resolution at the time of the A / D conversion,
The execution history information reading unit reads the control data as the processing data from the execution result stored in the execution result storage unit based on the resolution information.
前記制御データ毎に、そのデータ型が符号付きか否かを表す符号情報を記憶した符号情報記憶手段を備え、
前記実行履歴情報読取手段は、前記実行結果格納手段に記憶された実行結果から、前記符号情報に基づき、前記制御データを読み取ることを特徴とするソフトウェア結合検査装置。In the software combination inspection apparatus according to claim 3,
Code information storage means for storing code information indicating whether or not the data type is signed for each control data,
The execution history information reading unit reads the control data from the execution result stored in the execution result storage unit based on the code information.
前記制御データ毎に、そのデータ長を表すデータ長情報を記憶したデータ長情報記憶手段を備え、
前記実行履歴情報読取手段は、前記実行結果格納手段に記憶された実行結果から、前記データ長情報に基づき、前記制御データを読み取ることを特徴とするソフトウェア結合検査装置。In the software combination inspection apparatus according to claim 3 or 4,
A data length information storage means for storing data length information representing the data length for each control data,
The execution history information reading unit reads the control data from the execution result stored in the execution result storage unit based on the data length information.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP08402599A JP4200581B2 (en) | 1999-03-26 | 1999-03-26 | Software combination inspection device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP08402599A JP4200581B2 (en) | 1999-03-26 | 1999-03-26 | Software combination inspection device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000276375A JP2000276375A (en) | 2000-10-06 |
| JP4200581B2 true JP4200581B2 (en) | 2008-12-24 |
Family
ID=13819030
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP08402599A Expired - Fee Related JP4200581B2 (en) | 1999-03-26 | 1999-03-26 | Software combination inspection device |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4200581B2 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10592212B2 (en) | 2016-10-21 | 2020-03-17 | Samsung Electronics Co., Ltd. | System and method for software development based on procedures |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5736757B2 (en) * | 2010-12-10 | 2015-06-17 | セイコーエプソン株式会社 | Printing apparatus and printing method |
-
1999
- 1999-03-26 JP JP08402599A patent/JP4200581B2/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10592212B2 (en) | 2016-10-21 | 2020-03-17 | Samsung Electronics Co., Ltd. | System and method for software development based on procedures |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000276375A (en) | 2000-10-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7210123B2 (en) | Software evaluation system having source code and function unit identification information in stored administration information | |
| CA2266724C (en) | System for translating visual display object files and method of operation thereof | |
| EP1111483A1 (en) | Method and apparatus for assisting development of program for vehicle | |
| JP4200581B2 (en) | Software combination inspection device | |
| US20050216897A1 (en) | Converter, automation device with a converter, and a development environment having an automation device with converter | |
| US5522078A (en) | Automatic program generating apparatus using skeletons having fixed instruction areas and undefined instruction areas | |
| JP2006085708A (en) | Control device and control method for console | |
| US20080011819A1 (en) | Verification of hit testing | |
| JP2008077467A (en) | Display unit | |
| JP4562141B2 (en) | Programmable logic controller, information processing apparatus, control program, and table creation program | |
| JP2765549B2 (en) | Operation evaluation system in computer system | |
| US6993565B1 (en) | Service processor control system and computer-readable recording medium recording service processor control program | |
| JP4590907B2 (en) | Software development support device and software development support program | |
| JP7014199B2 (en) | Control systems, information processing equipment, and information processing programs | |
| JPH0573103A (en) | Operating parameter setting supporting device | |
| JP2947989B2 (en) | Image processing system | |
| JP4472295B2 (en) | Work management system for parts library conversion processing | |
| JP2757806B2 (en) | Circuit diagram error correction device | |
| JP2778491B2 (en) | CAD parts library check system | |
| CN112785264A (en) | Automatic input method and system of PC test information | |
| JP2003270300A (en) | Inspection device and method therefor | |
| JPH04281528A (en) | Software design specification confirming system | |
| JP2701451B2 (en) | Power measurement data processing system | |
| TW541456B (en) | Auxiliary debug method of super I/O conducted via serial port | |
| JP3358113B2 (en) | Program creation device for programmable controller |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050517 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080520 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080716 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080916 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080929 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111017 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121017 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121017 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131017 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |