WO2014030707A1 - 自己監視機能を備えたコンピュータ、監視プログラム - Google Patents

自己監視機能を備えたコンピュータ、監視プログラム Download PDF

Info

Publication number
WO2014030707A1
WO2014030707A1 PCT/JP2013/072439 JP2013072439W WO2014030707A1 WO 2014030707 A1 WO2014030707 A1 WO 2014030707A1 JP 2013072439 W JP2013072439 W JP 2013072439W WO 2014030707 A1 WO2014030707 A1 WO 2014030707A1
Authority
WO
WIPO (PCT)
Prior art keywords
program
input
monitoring
arithmetic
acquired
Prior art date
Application number
PCT/JP2013/072439
Other languages
English (en)
French (fr)
Inventor
真一 白石
正治 明井
太一 安藤
Original Assignee
トヨタ自動車株式会社
ＢＴＣ Ｊａｐａｎ株式会社
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by トヨタ自動車株式会社, ＢＴＣ Ｊａｐａｎ株式会社 filed Critical トヨタ自動車株式会社
Priority to CN201380044043.3A priority Critical patent/CN104583969B/zh
Priority to US14/423,309 priority patent/US9588878B2/en
Priority to EP13830967.9A priority patent/EP2889775B1/en
Publication of WO2014030707A1 publication Critical patent/WO2014030707A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis

Definitions

  • the present invention relates to a computer having a self-monitoring function and a monitoring program.
  • ECU Electronic Control Unit
  • Many computers for control by such an embedded system are used in fields other than automobiles, such as factory plants and production lines.
  • control computers such as ECUs
  • Control computers often have a self-diagnosis function to prevent accidents caused by failures or malfunctions.
  • the self-diagnosis function is called “diagnosis” or “OBD (On-board diagnostics)” (see Non-Patent Document 1).
  • the self-diagnosis function can detect an abnormal state such as the occurrence of an undefined signal in the computer, and can warn the user, stop the system, record log information, and the like.
  • a computer having a self-diagnosis function as described above can detect abnormal operation due to a circuit failure or a program failure and warn the user.
  • the self-diagnosis function can detect that the system is in an abnormal state, but cannot detect that the system is in a so-called “unverified state” before the system reaches an abnormal operation. .
  • a test scenario is generated assuming an operation performed by a user.
  • operations that are not assumed are often performed.
  • the software processes a scenario that has not been verified, so it cannot be guaranteed whether the processing can be normally performed. That is, a failure may occur in the scenario, which may cause the system to become unstable or cause an abnormal operation.
  • Such an unverified state is not a critical state, but has a risk in terms of software operation. Therefore, it is desirable to actively detect and notify. However, it has not been possible to detect whether or not a program running on a computer is running according to a verified scenario.
  • the present invention has been made in consideration of the above problems, and provides a computer having a self-monitoring function and a monitoring program capable of detecting that a user has performed an operation that does not exist in a test scenario.
  • the purpose is to do.
  • the first aspect of the present invention is a computer having a self-monitoring function.
  • a computer according to a first aspect of the present invention includes an input unit that acquires an input operation, a first program execution unit that executes an arithmetic program that performs an operation based on the input operation acquired by the input unit, Test scenario storage means for storing a plurality of test scenarios for the arithmetic program, and monitoring for determining whether the input operation acquired by the input means corresponds to any of the stored test scenarios And second program execution means for executing the program.
  • the calculation program is a program to be monitored, and is a program that performs calculation based on an input operation acquired through input means provided in the computer.
  • the input means is a human interface device such as a mouse, a touch panel, or a keyboard, and the input operation refers to information input from the user through the device. Specifically, it may be an event directly related to hardware such as click, tap, or key press, or a value input through a GUI (Graphical User Interface) component such as a text box, drop-down list, or slider. It may be.
  • GUI Graphic User Interface
  • the monitoring program is a program that acquires an input operation by a user and determines whether or not the input operation has been verified. Whether or not the input operation has been verified is determined by comparing the acquired input operation with a plurality of stored test scenarios.
  • the test scenario is data in which operations related to the test of the arithmetic program are recorded, and the monitoring program confirms whether the acquired input operation matches the content of the operation recorded in the test scenario. It can be determined whether or not the input operation has been verified.
  • Each of the test scenarios may include the contents and order of a plurality of input operations, and the monitoring program acquires a plurality of input operations from the input means, and the acquired plurality of input operations. However, when the content matches the content and order of the input operations included in any of the test scenarios, the acquired input operation may be determined to correspond to the test scenario.
  • the verification target may be a plurality of input operations. That is, by comparing the operations entered sequentially from the input means with the operations recorded in chronological order in the test scenario, and verifying that the content and order match, the entered operation becomes a test scenario. It can be determined whether it is a corresponding one.
  • the monitoring program notifies the arithmetic program or the external program that the system is in an unverified state when the acquired input operation does not correspond to any of the stored test scenarios. May be a feature.
  • the monitoring program notifies the arithmetic program and the external program that the operation has not been verified. Thereby, for example, processing for occurrence of an abnormality such as output to a system log, notification to an external system, and transition to a safe mode can be performed, and the safety of the system can be ensured.
  • the second aspect of the present invention is a monitoring program for monitoring an arbitrary program.
  • the monitoring program according to the second aspect of the present invention is a monitoring program that is executed simultaneously with a calculation program that performs a calculation and that monitors an input operation to the calculation program, and that acquires an input operation to the calculation program And an input determination step of determining whether the acquired input operation corresponds to any one of a plurality of test scenarios for the arithmetic program stored in advance.
  • Each of the stored test scenarios may include the contents and order of a plurality of input operations
  • the input acquisition step includes the input determination step
  • the acquired plurality of input operations include: When the contents and order of input operations included in any of the test scenarios match, the acquired input operations may be determined to correspond to the test scenario.
  • the arithmetic program or the external program is notified that the system is in an unverified state. It is good also as performing the step to perform.
  • the present invention can also be specified as a monitoring program that monitors input operations for an arbitrary program.
  • a third aspect of the present invention is a software creation device that generates a calculation program for performing a calculation and a monitoring program for monitoring an input operation on the calculation program.
  • a software creation device includes: an arithmetic program input unit that receives code input of the arithmetic program; and a test scenario input that receives input of a plurality of test scenarios for the arithmetic program described in a modeling language Monitoring means for determining whether an input operation to the arithmetic program corresponds to any of the plurality of test scenarios, including means, an arithmetic program generating means for generating the arithmetic program, and the plurality of test scenarios A monitoring program generating means for generating a program; the arithmetic program; and a program writing means for recording the monitoring program in an execution computer, wherein the arithmetic program generating means Place to do Process as a trigger for, characterized by adding a process of notifying an input operation performed on the operation program to the monitor program.
  • Each of the test scenarios may include the contents and order of a plurality of input operations, and the monitoring program acquires a plurality of input operations, and the acquired plurality of input operations are any one of them.
  • the content and order of the input operations included in the test scenario are matched, it is possible to determine that the acquired input operation corresponds to the test scenario.
  • the monitoring program can notify the arithmetic program or an external program that the system is in an unverified state when the input operation does not correspond to any of a plurality of test scenarios. It is good.
  • the present invention can also be specified as a software creation device that records a calculation program and a monitoring program in the computer according to the first aspect of the present invention. Note that the above processes and means can be freely combined and implemented as long as there is no technical contradiction.
  • FIG. 1 is a system configuration diagram of a computer according to a first embodiment. It is an example of a test scenario used for program monitoring. It is a figure explaining the state transition of the program by input operation. It is a processing flowchart of the computer concerning a first embodiment. It is a figure showing the circuit structure concerning 2nd embodiment.
  • FIG. 1 is a diagram for explaining a method for creating a calculation program and a monitoring program according to the present invention.
  • Java registered trademark
  • test scenario is a scenario written in a natural language for testing a program.
  • the scenario describes a series of operations performed by the user and the results thereof, and the developer tests the application code 15 while referring to the scenario.
  • the test scenario can also be described in UML (Unified Modeling Language). For example, if a sequence diagram (reference numeral 12) is used, it is possible to describe what kind of call is made between objects using a user operation as a trigger. Further, when a state chart (reference numeral 13) is used, it is possible to describe a change in the state of an object caused by a user operation.
  • FIG. 1 shows an example in which a test scenario (reference numeral 11) described in a natural language, a test scenario based on a sequence diagram (reference numeral 12), and a test scenario based on a state chart (reference numeral 13) are sequentially created. You only need to create one, not all.
  • the observer code is a code created based on the test scenario, and is the source code of a monitoring program that monitors whether the arithmetic program is operating according to the test scenario.
  • a technology for automatically generating an observer code from a state chart described in UML there is Rational® Rhapsody (registered trademark) of IBM Corporation.
  • Rational® Rhapsody registered trademark of IBM Corporation.
  • an observer is manually created by referring to a test scenario (reference numeral 11) described in a natural language or a test scenario (reference numeral 12) based on a sequence diagram. You may create code.
  • the observer code 14 is created for each test scenario described above.
  • the build is performed using aspect-oriented programming so that both programs can exchange information with each other. Details of aspect-oriented programming will be described later. Finally, the actual product is completed by writing the built module into a microcomputer or in-vehicle computer.
  • FIG. 2 is a diagram showing the system configuration of the software creation apparatus according to the present invention.
  • the software requirement storage unit 21 is a means for storing a software requirement (reference numeral 10) that describes a request to be satisfied by software.
  • the software requirement may be described in a natural language, or may be described using a specification description language such as LTL (Linear Temporal Logic) or CTL (Computational Tree Logic) for describing software specifications.
  • the test scenario generation unit 22 is means for creating a test scenario based on software requirements. As described above, the test scenario may be described in a natural language, or may be described by a sequence diagram or a state chart. When a test scenario is described in UML, various UML plug-ins provided for Eclipse can be used. The software developer creates a test scenario using an editor provided by the test scenario generation unit 22.
  • the code generation unit 23 is a means for creating the application code 15.
  • the code may be created by manually coding using an editor, or a software model may be created and automatically generated from the software model.
  • Various design tools provided for Eclipse can also be used for creating a software model and generating application code. For example, using a development tool such as Simulink (registered trademark) of MathWorks, application code can be automatically generated from a software model.
  • the observer generation unit 24 is means for generating an observer code from the test scenario generated by the test scenario generation unit 22. As described above, since one observer code corresponds to one test scenario, when there are a plurality of test scenarios, a plurality of observer codes are generated by the observer generation unit 24. When a state chart is created by the test scenario generation unit 23, the Java observer code can be automatically generated by the above-described Rational Rhapsody. Observer codes may be manually created from a test scenario (reference numeral 11) in a natural language or a test scenario (reference numeral 12) in a sequence diagram.
  • the code synthesizing unit 25 is means for synthesizing and building the observer code generated by the observer generating unit 24 and the application code generated by the code generating unit 23. As described above, since the observer code and the application code are independent of each other, it is not possible to refer to each other as they are, and it is impossible to monitor the input operation performed on the arithmetic program. Therefore, in this embodiment, transfer of input operations between codes is realized by aspect-oriented programming.
  • Aspect-oriented programming is a technique for incorporating concepts that cannot be classified by objects into programs.
  • additional functions that are difficult to classify such as logging, assertion, and error processing, and that are not original functional processes can be incorporated into the program.
  • This process is called an aspect, and an execution point that incorporates the aspect is called a join point. That is, the process of passing the input operation to the observer code is used as an aspect, and the join point is arranged in the observer code and the application code, so that the user can pass the input operation.
  • a software developer can add a function without modifying the already created code simply by creating an aspect and specifying a join point.
  • a representative example of an aspect-oriented language is AspectJ.
  • AspectJ is a language to which specifications for realizing aspect-oriented programming are added to the Java language.
  • the code synthesis unit 25 connects the application code and the observer code using AspectJ. Specifically, a code for passing an input operation is created as an aspect, and a joint point is defined in a portion of the application code and the observer code where the input operation is to be passed. As a result, the monitoring program can acquire an input operation for the arithmetic program. Code synthesis is performed using the AspectJ plug-in provided for Eclipse.
  • FIG. 3 is a diagram illustrating a configuration of a program generated by the software creation device according to the first embodiment.
  • the arithmetic program generated from the application code is referred to as a monitoring target program
  • the monitoring program generated from the observer code is referred to as an observer.
  • the application code and the observer code are built by the code synthesis unit 25, and the execution program 30 is generated.
  • the execution program 30 includes a monitoring target program 32 that is a program corresponding to the application code, and a plurality of observers 31A, 31B, 31C... That are programs corresponding to the respective observer codes. Input operations performed on the monitoring target program are also input to each observer substantially simultaneously. Note that the monitoring target program and each observer may be stored in one module or may be divided into a plurality of modules as long as the condition that they are executed simultaneously is satisfied.
  • the master observer 31M is a program for checking the states of the plurality of observers.
  • the master observer 31M is stored in the observer generation unit 24 as a common program that does not depend on the application, and is built at the same time by the code synthesis unit 25.
  • the range of the reference numeral 31 shown in FIG. 3 is the monitoring program in the present invention. The operation of the master observer will be described later.
  • the generated execution program 30 is written by the code writing unit 26 into a storage device (ROM) of a computer operating in a real environment.
  • the computer that operates in a real environment is, for example, an in-vehicle computer (ECU) that is installed in an automobile.
  • ECU in-vehicle computer
  • FIG. 4 is a flowchart showing a software development procedure according to the first embodiment.
  • the software developer generates an application code from the software requirement in the code generation unit 23 (S11), and designs a test scenario from the software requirement in the test scenario generation unit 22 (S12). Either of the procedures of step S11 and step S12 may be performed first or in parallel.
  • the observer generation unit 24 generates an observer code from the test scenario (S13), and then the code synthesis unit 25 builds both the application code and the observer code (S14). Thereby, the execution program 30 is obtained.
  • the code writing unit 26 writes the generated execution program 30 into the target computer (S15), and the software development is completed.
  • FIG. 5 is a system configuration diagram of the in-vehicle terminal 100 in which the execution program 30 is executed.
  • the in-vehicle terminal 100 includes an arithmetic processing device 101 and a storage device 102.
  • the execution program 30 is stored in the storage device 102 and is executed by the arithmetic processing device 101.
  • the user can perform input to the monitoring target program 32 through the input device 103.
  • the input device 103 is a touch panel in the present embodiment, but may be a keyboard or a pointing device.
  • the in-vehicle terminal 100 includes a communication device 104 for performing wireless communication with the outside, and a disk device 105 for recording information.
  • FIG. 6 is an example of a test scenario held by each observer.
  • FIG. 7 is a diagram showing the state transition of the monitoring program by the user's operation. For example, after the transition from the main menu to the submenu 1, the operation can be performed in the order of operation A, operation B, operation C, and operation D.
  • Test scenarios corresponding to this series of operations are test scenarios 1 and 2. In each test scenario, the sequence of operations when the program is tested is recorded, and each observer (31A, 31B, 31C%) Stores one test scenario at a time. In this example, six observers are used to monitor all the test scenarios shown in FIG.
  • the operation has been confirmed at the test stage of the program. It can be seen that it is. Conversely, if an operation that does not match any test scenario is performed, it can be determined that the operation has not been confirmed, that is, the unverified state.
  • the method for determining which test scenario the input operation currently performed by the user matches will be described using the term “active / inactive” of the observer.
  • “The observer is in an active state” means that the input operation performed by the user is in a situation that matches the test scenario possessed by the observer. Further, “the observer is in an inactive state” means that the operation performed by the user does not match the test scenario possessed by the observer.
  • Each observer can switch the state (active state / inactive state) of the own observer according to the comparison result between the acquired input operation and the test scenario stored in the own observer.
  • Each test scenario starts from a starting screen.
  • the main menu screen is the starting point for all test scenarios. That is, in a state where the monitoring target program displays the main menu, the state corresponds to all the test scenarios, and all the observers are activated.
  • the operation performed by the user is first input to the monitoring target program.
  • a join point is defined together with a function for acquiring an input operation, and an aspect is executed every time a user performs an input operation.
  • the aspect describes a process for acquiring an input operation and transmitting it to the observer, whereby the input operation is transmitted to all the observers. For example, when “menu transition operation 1” is performed, the operation is transmitted to all observers.
  • a list of observers in the active state when the following operations are sequentially performed from the main menu is as follows.
  • the observers corresponding to the exemplified test scenarios 1 to 6 are referred to as observers 1 to 6, respectively.
  • Operation Z Observer 1, 2, 3, 4, 5, 6
  • the monitoring program 31 can determine whether or not the monitoring target program 32 is in a verified state based on the active state of the observer.
  • the monitoring process performed by the monitoring program 31 operating on the in-vehicle terminal 100 is shown in the flowchart of FIG.
  • the execution program 30 is started on the in-vehicle terminal 100, the flowchart of FIG. 8 is started.
  • step S21 every time a user performs an input operation, all observers acquire the input operation.
  • steps S22 and S23 each observer compares the operation acquired in step S21 with the test scenario that the observer has. As a result, when the own observer is an activation target, it is switched to an active state (S22), and when it is a deactivation target, it is switched to an inactive state (S23). The inactivated observer notifies the master observer 31M that it has been deactivated.
  • Step S24 is a step for detecting that all observers are inactive.
  • the master observer 31M counts the number of observers in the active state.
  • the process proceeds to step S25, and the master observer 31M generates an event of user failure.
  • a user failure is an event for notifying that a program is in an unverified state. For example, when the system that controls the vehicle is in a user failure state, it is conceivable to shift the system to a safe mode that is the minimum configuration necessary for driving. Further, when the situation is considered to be relatively safe, only the notification to the driver may be performed.
  • the master observer 31M activates an external program for notifying the abnormality, and the external program notifies the driver that an abnormality has occurred through a display (not shown) such as an LED or LCD. To do.
  • related information is recorded in the disk device 105 as a log. Information to be recorded is a memory dump of the program, a log of operations performed by the user, and the like. The log information may be transmitted to the management center 200 through the communication device 104. Further, notification that an abnormality has occurred may be made to the monitoring target program. If there is one or more observers in the active state, the process proceeds to step S21 and waits for an input operation again.
  • the observer executed on the computer can detect that the input operation of the untested pattern has been performed by the user by monitoring the input to the monitoring target program.
  • notification can be made before the system becomes critical, and the safety of the system can be improved.
  • the master observer when all the observers are deactivated, the master observer generates a user failure.However, a separate program for checking the observer active state is provided, and all the observers are deactivated. When it becomes active, the program may generate a user failure.
  • the operation when a user failure occurs, the operation is terminated after performing necessary processing. However, when the observer is activated again after the user failure occurs, the recovery processing is performed. You may make it continue monitoring after performing.
  • the recovery process may be a process of notifying the outside that the state has been verified again, or a process of returning the system mode from the safe mode to the normal mode.
  • the main menu is the starting point for each test scenario, and all observers are activated when the screen transitions to the main menu.
  • the timing of observer activation is arbitrary according to the test scenario. The timing can be as follows. For example, there may be an observer that is activated when transitioning to a submenu, or there may be an observer that is activated when an arbitrary condition is satisfied.
  • the target language may be other than Java. If an aspect-oriented framework can be used, for example, C language, C ++, PHP, or the like may be used. If an input operation to the monitored program can be notified to the observer by some method, the aspect-oriented programming may not be used. Also good. For example, if EmbeddedTester, a development tool by BTC Embedded Systems AG, is used, an observer and a program generated in C language can be connected to each other and the program can be monitored.
  • an aspect-oriented framework for example, C language, C ++, PHP, or the like may be used. If an input operation to the monitored program can be notified to the observer by some method, the aspect-oriented programming may not be used. Also good. For example, if EmbeddedTester, a development tool by BTC Embedded Systems AG, is used, an observer and a program generated in C language can be connected to each other and the program can be monitored.
  • EmbeddedTester a development tool by BTC
  • FIG. 9 is a diagram illustrating a circuit configuration according to the second embodiment.
  • a program is generated by a software creation device as in the first embodiment, but differs from the first embodiment in the following points.
  • the code generated by the code generation unit 23 and the observer generation unit 24 is not Java, but a hardware description language such as AHDL or VHDL. Further, the code synthesis unit 25 does not synthesize the code, and the monitoring target program and the observer are built separately. In the code writing unit 26, the monitoring target program and the observer are individually written in a digital circuit such as an integrated circuit.
  • the software development procedure is the same as the flowchart shown in FIG.
  • FIG. 9 is a diagram showing the relationship between the monitoring target circuit 41 in which the monitoring target program is written and the observer circuit 42 in which a plurality of observers are written.
  • the monitoring target circuit 41 is a circuit that executes a program to be monitored, that is, the monitoring target program 32 in the first embodiment.
  • the observer circuit 42 is a circuit that executes a program for monitoring, that is, the master observer 31M in the first embodiment and a plurality of observers (31A, 31B, 31C).
  • the observer circuit 42 acquires an operation signal input from the user interface to the monitoring target circuit 41 via the input signal line, and performs the processing illustrated in FIG. When a user fail process occurs, an abnormality is reported to the outside through the abnormality signal line.
  • the circuit that controls the system acquires this and can take the same action as in the first embodiment. For example, the user may be notified, or the mode may be shifted to a mode in which a part of the system is restricted. Further, the corresponding circuit may be disconnected from the system.
  • the present invention can also be applied to a program that operates on an integrated circuit, not on a computer. While the first embodiment operates on the same computer, in this embodiment, since the observer is written in a separate integrated circuit, the circuit on which the monitored system operates and the circuit on which the observer operates It has the advantage that it can be designed separately.
  • the observer is activated and deactivated every time the user performs some input operation.
  • input operations not related to the test scenario may be discarded in step S21.
  • Good For example, when an input is made from a keyboard and the input is made in a text box, the process is stopped in step S21 until the input confirmation button is pressed, and the process waits. May be.
  • a simple input such as a click or a tap for changing the state of the program is exemplified as the input operation.
  • the input operation may be accompanied by an input value.
  • the observer may be deactivated as not corresponding to the test scenario.
  • any input operation recorded in the test scenario may be defined as long as it is associated with the operation by the user.
  • the present invention performs verification / non-verification status determination based on an input operation by a user, but adds a function for determining a match with a test scenario based on external input data.
  • a function of determining a match with the test scenario based on data generated inside the system may be added.
  • the present invention can be applied to various things as long as the test scenario is compared with the actual operation.

Abstract

　コンピュータに、入力操作を取得する入力手段と、前記入力手段が取得した入力操作をもとに演算を行う演算プログラムが実行される第一のプログラム実行手段と、前記演算プログラムに対する複数のテストシナリオを記憶したテストシナリオ記憶手段と、前記入力手段が取得した入力操作が、前記記憶された複数のテストシナリオのうち、いずれかと対応するものであるかを判定する監視プログラムが実行される第二のプログラム実行手段と、を具備させる。

Description

自己監視機能を備えたコンピュータ、監視プログラム
　本発明は、自己監視機能を備えたコンピュータ、および監視プログラムに関する。
　近年、組み込みシステムによって機器の状態を制御することが一般的になっている。例えば、自動車に搭載されたコンピュータは、ＥＣＵ（エレクトリックコントロールユニット）と呼ばれ、走行に関する様々な制御を行っている。このような組み込みシステムによる制御用コンピュータは、工場プラントや製造ラインなど、自動車以外の分野においても数多く利用されている。
　ＥＣＵをはじめとする制御用コンピュータにおいては、仕様に従って正しくプログラムが動作していることを保証する必要がある。回路の故障やプログラムの不具合によって予期せぬ動作が発生すると、車両やラインを正常に制御することができなくなり、利用者の安全を脅かすためである。
　制御用のコンピュータにおいては、故障や不具合に起因する事故を防止するため、自己診断機能が備えられている場合が多い。自動車の場合、自己診断機能は「ダイアグノーシス（diagnosis）」や「ＯＢＤ（On-board diagnostics）」と呼ばれている（非特許文献１参照）。自己診断機能は、コンピュータの内部で、定義されていない信号が発生した等の異常な状態を検知して、利用者への警告やシステムの停止、ログ情報の記録などをすることができる。
" ODB-II On-Board Diagnostics"、［online］、B&B Electronics、［平成２４年７月２３日検索］、インターネット＜URL：http://www.obdii.com/＞
　前述したような自己診断機能を有するコンピュータは、回路の故障やプログラムの不具合による異常動作を検出し、利用者に警告することができる。しかし、自己診断機能は、システムが異常な状態となったことを検知することはできるが、システムが異常動作に至る前の、いわゆる「検証されていない状態」であることを検出することはできない。
　この問題について詳しく説明する。一般的に、ソフトウェアのテストにおいては、利用者が行う操作を想定してテストシナリオを生成する。しかし、全てのケースを完全に網羅することは容易ではなく、想定されていない操作が行われることが少なからずある。このような想定外の操作が行われた場合、ソフトウェアは検証されていないシナリオを処理することとなるため、正常に処理が行えるかが保証できない。すなわち、当該シナリオにおいて不具合が発生し、システムが不安定になったり、異常動作を引き起こしたりする可能性がある。このような未検証の状態は、クリティカルな状態ではないものの、ソフトウェアの動作上リスクを抱えた状態であるため、積極的に検出して通知を行うことが望ましい。しかし、コンピュータで動作中のプログラムが、検証済みのシナリオに沿って動作しているのか否かについては、従来の技術では検出することができなかった。
　本発明は上記の問題点を考慮してなされたものであり、利用者がテストシナリオに存在しない操作を行ったことを検出することができる、自己監視機能を備えたコンピュータ、および監視プログラムを提供することを目的とする。
　本発明の第一の形態は、自己監視機能を備えたコンピュータである。
　本発明の第一の形態に係るコンピュータは、入力操作を取得する入力手段と、前記入力手段が取得した入力操作をもとに演算を行う演算プログラムが実行される第一のプログラム実行手段と、前記演算プログラムに対する複数のテストシナリオを記憶したテストシナリオ記憶手段と、前記入力手段が取得した入力操作が、前記記憶された複数のテストシナリオのうち、いずれかと対応するものであるかを判定する監視プログラムが実行される第二のプログラム実行手段と、を有することを特徴とする。
　演算プログラムとは、監視の対象となるプログラムであり、コンピュータに備えられた入力手段を通して取得された入力操作に基づいて演算を行うプログラムである。入力手段とは、マウス、タッチパネル、キーボード等のヒューマンインタフェースデバイスであり、入力操作とは、当該デバイスを通して利用者から入力された情報を指す。具体的には、クリック、タップ、キー押下などのハードウェアと直接関連付いたイベントであってもよいし、テキストボックス、ドロップダウンリスト、スライダなどのＧＵＩ（Graphical User Interface）部品を通して入力される値であってもよい。
　また、監視プログラムとは、利用者による入力操作を取得し、当該入力操作が検証済みであるか否かを判定するプログラムである。入力操作が検証済みであるか否かの判定は、取得した入力操作と、記憶している複数のテストシナリオとを対比させることで行う。テストシナリオとは、演算プログラムのテストに係る操作が記録されたデータであり、監視プログラムは、取得した入力操作と、テストシナリオに記録された操作の内容が一致するかを確認することで、当該入力操作が検証済みであるか否かを判定することができる。
　また、前記各テストシナリオは、複数の入力操作の内容および順序をそれぞれ含むことを特徴としてもよく、前記監視プログラムは、前記入力手段から複数の入力操作を取得し、前記取得した複数の入力操作が、いずれかのテストシナリオに含まれる入力操作の内容および順序と一致した場合に、前記取得した入力操作が、当該テストシナリオに対応するものであると判定することを特徴としてもよい。
　このように、検証の対象は複数の入力操作であってもよい。すなわち、入力手段から順次入力される操作と、テストシナリオに時系列順に記録された操作とを比較し、その内容および順序が一致しているかを検証することで、入力された操作がテストシナリオに対応したものであるかを判定することができる。
　また、前記監視プログラムは、前記取得した入力操作が、記憶した複数のテストシナリオのいずれとも対応しない場合に、前記演算プログラムまたは外部プログラムに対して、システムが未検証状態である旨を通知することを特徴としてもよい。
　利用者が行った操作が、記憶している複数のテストシナリオのいずれとも対応しない場合、当該操作は検証されていない操作であると判定できる。この場合、監視プログラムが、演算プログラムや外部プログラムに対して、動作が検証されていない状況であることを通知する。これにより、例えば、システムログへの出力、外部システムへの通知、セーフモードへの移行など、異常発生に備えた処理を行うことができ、システムの安全を担保することができる。
　本発明の第二の形態は、任意のプログラムを監視する監視プログラムである。
　本発明の第二の形態に係る監視プログラムは、演算を行う演算プログラムと同時に実行され、前記演算プログラムに対する入力操作を監視する監視プログラムであって、前記演算プログラムに対する入力操作を取得する入力取得ステップと、前記取得した入力操作が、事前に記憶された、前記演算プログラムに対する複数のテストシナリオのうちいずれかと対応するものであるかを判定する入力判定ステップと、を含むことを特徴とする。
　また、前記記憶された各テストシナリオは、複数の入力操作の内容および順序をそれぞれ含むことを特徴としてもよく、前記入力取得ステップは、前記入力判定ステップは、前記取得した複数の入力操作が、いずれかのテストシナリオに含まれる入力操作の内容および順序と一致した場合に、前記取得した入力操作が、当該テストシナリオに対応するものであると判定することを特徴としてもよい。
　また、前記入力判定ステップにおいて、前記取得した入力操作が、記憶された複数のテストシナリオのいずれとも対応しない場合に、前記演算プログラムまたは外部プログラムに対して、システムが未検証状態である旨を通知するステップを実行することを特徴としてもよい。
　このように、本発明は、任意のプログラムに対する入力操作を監視する監視プログラムとして特定することもできる。
　本発明の第三の形態は、演算を行う演算プログラムと、前記演算プログラムに対する入力操作を監視する監視プログラムと、を生成するソフトウェア作成装置である。
　本発明の第三の形態に係るソフトウェア作成装置は、前記演算プログラムのコード入力を受け付ける演算プログラム入力手段と、モデリング言語によって記述された、前記演算プログラムに対する複数のテストシナリオの入力を受け付けるテストシナリオ入力手段と、前記演算プログラムを生成する演算プログラム生成手段と、前記複数のテストシナリオを含み、前記演算プログラムに対する入力操作が、前記複数のテストシナリオのうちいずれかと対応するものであるかを判定する監視プログラムを生成する監視プログラム生成手段と、前記演算プログラムと、監視プログラムを実行用コンピュータに記録するプログラム書き込み手段と、を有し、前記演算プログラム生成手段は、前記演算プログラムに対し、前記演算プログラムが行う所定の処理をトリガとして、前記演算プログラムに対して行われた入力操作を前記監視プログラムに通知する処理を追加することを特徴とする。
　また、前記各テストシナリオは、複数の入力操作の内容および順序をそれぞれ含むことを特徴としてもよく、前記監視プログラムは、複数の入力操作を取得し、前記取得した複数の入力操作が、いずれかのテストシナリオに含まれる入力操作の内容および順序と一致した場合に、前記取得した入力操作が、当該テストシナリオに対応するものであると判定することを特徴としてもよい。
　また、前記監視プログラムは、前記入力操作が、複数のテストシナリオのいずれとも対応しない場合に、前記演算プログラムまたは外部プログラムに対して、システムが未検証状態である旨を通知可能であることを特徴としてもよい。
　このように、本発明は、本発明の第一の形態に係るコンピュータに、演算プログラムおよび監視プログラムを記録するソフトウェア作成装置として特定することもできる。なお、上記処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。
　本発明によれば、利用者がテストシナリオに存在しない操作を行ったことを検出することができる、自己監視機能を備えたコンピュータ、および監視プログラムを提供することができる。
オブザーバコードおよびアプリケーションコードの作成方法を説明する図である。 本発明におけるソフトウェア作成装置のシステム構成図である。 本発明における実行プログラムの構成を表す図である。 ソフトウェア開発のフローチャートである。 第一の実施形態に係るコンピュータのシステム構成図である。 プログラムの監視に用いるテストシナリオの例である。 入力操作によるプログラムの状態遷移を説明する図である。 第一の実施形態に係るコンピュータの処理フローチャートである。 第二の実施形態に係る回路構成を表した図である。
（第一の実施形態）
 <プログラム開発方法の概要>
　本発明に係る監視プログラム、および監視対象となる演算プログラムの開発方法について概要を説明する。図１は、本発明に係る演算プログラムおよび監視プログラムの作成方法を説明する図である。本実施形態では、オープンソースで提供されている統合開発環境であるＥｃｌｉｐｓｅを用いて、Ｊａｖａ（登録商標）アプリケーションを作成する例について述べる。
　ソフトウェアを作成する際は、設計の基礎となるソフトウェア要件（符号１０）を最初に定義する必要がある。ソフトウェア要件とは、ソフトウェアが満たすべき要求を定義したものである。ソフトウェア要件は、自然言語によって記述してもよいし、コンピュータが直接解釈できる仕様記述言語などの言語によって記述してもよい。
　ソフトウェア開発者は、定義したソフトウェア要件からプログラムを設計し、演算プログラムのソースコードであるアプリケーションコード（符号１５）の作成を行う。ここでは、プログラム設計についての記述は省略しているが、例えば、ソフトウェア要件からソフトウェアモデルを作成し、コードを生成してもよいし、ソフトウェア要件からプログラム設計を作成し、手作業でコーディングを行ってもよい。アプリケーションコード１５の生成には、既知の技術および手法を用いることができる。
　また、ソフトウェア開発者は、ソフトウェア要件からテストシナリオ（符号１１）を作成する。テストシナリオとは、プログラムに対してテストを行うための、自然言語で記述されたシナリオである。当該シナリオには、利用者による一連の操作と、それに対する結果が記述されており、開発者は、当該シナリオを参照しながらアプリケーションコード１５のテストを行う。
　テストシナリオは、ＵＭＬ（Unified Modeling Language：統一モデル言語）によって記述することもできる。例えば、シーケンスダイアグラム（符号１２）を用いると、利用者の操作をトリガとして、オブジェクト間でどのような呼び出しが行われるかを記述することができる。また、ステートチャート（符号１３）を用いると、利用者の操作に起因したオブジェクトの状態変化を記述することができる。図１では、自然言語で記述されたテストシナリオ（符号１１）、シーケンスダイアグラムによるテストシナリオ（符号１２）、ステートチャートによるテストシナリオ（符号１３）を順番に作成する例を示したが、テストシナリオはいずれかを作成すればよく、全てを作成する必要は無い。
　オブザーバコード（符号１４）は、テストシナリオに基づいて作成されるコードであり、演算プログラムがテストシナリオに沿った動作をしているかを監視する監視プログラムのソースコードである。例えば、ＵＭＬによって記述されたステートチャートからオブザーバコードを自動生成する技術として、ＩＢＭ社のRational Rhapsody（登録商標）がある。ここでは、ステートチャートからオブザーバコードを自動生成する例を挙げたが、自然言語で記述されたテストシナリオ（符号１１）、またはシーケンスダイアグラムによるテストシナリオ（符号１２）を参照して、手作業でオブザーバコードを作成してもよい。オブザーバコード１４は、前述したテストシナリオごとに作られる。
　オブザーバコード１４とアプリケーションコード１５は、互いに独立しているため、オブザーバコードから監視プログラムを生成しても、そのままでは演算プログラムに対して行われる入力操作の監視を行うことができない。そこで、本実施形態では、アスペクト指向プログラミングを利用し、双方のプログラムが互いに情報を交換できるようにしたうえでビルドを行う。アスペクト指向プログラミングについての詳細は後述する。最終的に、ビルドしたモジュールをマイコンや車載コンピュータなどに書き込むことにより、実際の製品が完成する。
 <ソフトウェア作成装置>
　第一の実施形態に係るソフトウェア作成装置について、詳細に説明する。図２は、本発明に係るソフトウェア作成装置のシステム構成を表した図である。
　ソフトウェア要件記憶部２１は、ソフトウェアが満たすべき要求を記述した、ソフトウェア要件（符号１０）を記憶する手段である。ソフトウェア要件は、自然言語で記述してもよいし、ソフトウェアの仕様を記述するためのＬＴＬ（Linear Temporal Logic）や、ＣＴＬ（Computational Tree Logic）といった仕様記述言語を用いて記述してもよい。
　テストシナリオ生成部２２は、ソフトウェア要件に基づいたテストシナリオを作成する手段である。テストシナリオは、前述した通り、自然言語で記述してもよいし、シーケンスダイアグラムやステートチャートによって記述してもよい。テストシナリオをＵＭＬによって記述する場合、Ｅｃｌｉｐｓｅ用に提供されている各種ＵＭＬプラグインを利用することができる。ソフトウェア開発者は、テストシナリオ生成部２２が提供するエディタによってテストシナリオを作成する。
　コード生成部２３は、アプリケーションコード１５を作成する手段である。コードは、エディタを利用して手作業でコーディングすることで作成してもよいし、ソフトウェアモデルを作成し、ソフトウェアモデルから自動生成してもよい。ソフトウェアモデルの作成やアプリケーションコードの生成にも、Ｅｃｌｉｐｓｅ用に提供されている各種設計ツールを利用することができる。例えば、MathWorks社のSimulink（登録商標）といった開発ツールを用いると、ソフトウェアモデルからアプリケーションコードを自動生成することができる。
　オブザーバ生成部２４は、テストシナリオ生成部２２で生成したテストシナリオから、オブザーバコードを生成する手段である。前述したように、一つのオブザーバコードは一つのテストシナリオに対応するため、テストシナリオが複数ある場合、複数のオブザーバコードがオブザーバ生成部２４によって生成される。
　テストシナリオ生成部２３でステートチャートを作成した場合、前述したRational Rhapsodyにより、Ｊａｖａのオブザーバコードを自動生成することができる。オブザーバコードは、自然言語によるテストシナリオ（符号１１）やシーケンスダイアグラムによるテストシナリオ（符号１２）から手動で作成しても勿論構わない。
　コード合成部２５は、オブザーバ生成部２４が生成したオブザーバコードと、コード生成部２３が生成したアプリケーションコードを合成してビルドする手段である。前述したように、オブザーバコードとアプリケーションコードは互いに独立しているため、そのままでは互いを参照することができず、演算プログラムに対して行われた入力操作を監視することができない。そこで本実施形態では、アスペクト指向プログラミングによって、コード間での入力操作の転送を実現する。
　アスペクト指向プログラミングについて説明する。アスペクト指向プログラミング（Aspect Oriented Programming）とは、オブジェクトで分類できない概念をプログラムに織り込むための技術である。アスペクト指向プログラミングを用いると、例えば、ロギングやアサーション、エラー処理など、クラス分類が難しい機能であって、本来の機能的処理ではない付加的な処理をプログラム中に織り込むことができる。当該処理をアスペクトと呼び、アスペクトを織り込む実行地点をジョインポイントと呼ぶ。すなわち、入力操作をオブザーバコードに渡す処理をアスペクトとし、オブザーバコードおよびアプリケーションコード内にジョインポイントを配置することで、利用者による入力操作を受け渡すことができる。このように、ソフトウェア開発者は、アスペクトを作成し、ジョインポイントを指定するだけで、既に作成されているコードに手を加えることなく機能を追加することができる。
　アスペクト指向言語の代表例として、ＡｓｐｅｃｔＪがある。ＡｓｐｅｃｔＪは、Ｊａｖａ言語に対してアスペクト指向プログラミングを実現するための仕様が追加された言語である。コード合成部２５は、ＡｓｐｅｃｔＪを用いて、アプリケーションコードとオブザーバコードを連結する。具体的には、入力操作を受け渡すコードをアスペクトとして作成し、アプリケーションコード内およびオブザーバコード内の、入力操作を受け渡したい部分にジョイントポイントを定義する。これにより、演算プログラムに対する入力操作を監視プログラムが取得することができるようになる。コードの合成は、Ｅｃｌｉｐｓｅ用に提供されているＡｓｐｅｃｔＪプラグインを用いて行う。
　図３は、第一の実施形態に係るソフトウェア作成装置によって生成されたプログラムの構成を表す図である。なお、実施形態の説明では、アプリケーションコードから生成された演算プログラムを監視対象プログラム、オブザーバコードから生成された監視プログラムをオブザーバと称する。
　コード合成部２５によって、アプリケーションコードとオブザーバコードがビルドされ、実行プログラム３０が生成される。実行プログラム３０には、アプリケーションコードに対応するプログラムである監視対象プログラム３２と、各オブザーバコードに対応するプログラムである複数のオブザーバ３１Ａ，３１Ｂ，３１Ｃ…が含まれる。監視対象プログラムに対して行った入力操作は、各オブザーバにも略同時に入力される。なお、監視対象プログラムと各オブザーバは、同時に実行するという条件を満たせば、一つのモジュールに格納されていてもよいし、複数のモジュールに分かれていてもよい。また、マスタオブザーバ３１Ｍは、前記複数のオブザーバの状態をチェックするためのプログラムである。マスタオブザーバ３１Ｍは、アプリケーションに依存しない共通のプログラムとしてオブザーバ生成部２４に記憶され、コード合成部２５にて同時にビルドされる。図３に示した符号３１の範囲が、本発明における監視プログラムである。マスタオブザーバの動作については後述する。
　生成された実行プログラム３０は、コード書込部２６にて、実環境で動作するコンピュータが有する記憶装置（ＲＯＭ）に書き込まれる。実環境で動作するコンピュータとは、例えば自動車に搭載される車載コンピュータ（ＥＣＵ）などである。
　図４は、第一の実施形態に係るソフトウェア開発手順を表したフロー図である。ソフトウェア開発者は、コード生成部２３にて、ソフトウェア要件からアプリケーションコードを生成し（Ｓ１１）、また、テストシナリオ生成部２２にて、ソフトウェア要件からテストシナリオを設計する（Ｓ１２）。ステップＳ１１とステップＳ１２の手順は、どちらかを先に行ってもよいし、並列して行ってもよい。
　そして、オブザーバ生成部２４にて、テストシナリオからオブザーバコードを生成（Ｓ１３）したのち、コード合成部２５にて、アプリケーションコードとオブザーバコードの双方をビルドする（Ｓ１４）。これにより、実行プログラム３０が得られる。最終的に、コード書込部２６にて、生成された実行プログラム３０を対象のコンピュータに書き込み（Ｓ１５）、ソフトウェア開発が完了する。
 <プログラムの監視方法>
　次に、コンピュータに書き込まれたプログラムの動作を説明する。本実施形態においては、コンピュータとは、車両に搭載される車載端末である。図５は、実行プログラム３０が実行される車載端末１００のシステム構成図である。
　車載端末１００は、演算処理装置１０１および記憶装置１０２を有している。実行プログラム３０は、記憶装置１０２に格納されており、演算処理装置１０１にて実行される。また、利用者は、監視対象プログラム３２に対する入力を、入力装置１０３を通して行うことができる。入力装置１０３は、本実施形態ではタッチパネルであるが、キーボードやポインティングデバイスであってもよい。
　また、車載端末１００は、外部との無線通信を行うための通信装置１０４、および情報を記録するためのディスク装置１０５を有している。
　監視対象プログラムに対する入力操作が、テストシナリオに沿っているかをオブザーバが判定する方法を、具体的な例で説明する。図６は、各オブザーバが保持しているテストシナリオの例である。また、図７は、利用者の操作による監視プログラムの状態遷移を表した図である。例えば、メインメニューからサブメニュー１に遷移した後に、操作Ａ、操作Ｂ、操作Ｃ、操作Ｄの順番で操作を行うことができる。この一連の操作に該当するテストシナリオは、テストシナリオ１および２である。各テストシナリオには、このように、プログラムのテストを行った際の操作の順序が記録されており、各オブザーバ（３１Ａ，３１Ｂ，３１Ｃ…）は、テストシナリオを一つずつ記憶している。本例では、図６に示したテストシナリオを全て監視するために６個のオブザーバが用いられる。
　利用者が現に行っている入力操作が、いずれかのオブザーバが記憶しているテストシナリオに記録された操作と一致している限り、当該操作は、プログラムのテスト段階で動作確認がとれているものであることがわかる。逆に、どのテストシナリオにも一致しない操作が行われた場合は、動作確認がされていない状態、すなわち未検証状態であると判定することができる。
　利用者が現に行っている入力操作が、どのテストシナリオに一致しているかを判断するための方法を、オブザーバの活性／非活性という語を用いて説明する。「オブザーバが活性状態にある」とは、利用者が行っている入力操作が、当該オブザーバが有しているテストシナリオと一致している状況にあることを意味する。また、「オブザーバが非活性状態にある」とは、利用者が行っている操作が、当該オブザーバが有しているテストシナリオと一致していない状況にあることを意味する。各オブザーバは、取得した入力操作と、自オブザーバが記憶しているテストシナリオとの比較結果に応じて、自オブザーバの状態（活性状態／非活性状態）を切り替えることができる。
　具体的な例を挙げて説明する。テストシナリオは、それぞれ起点となる画面からスタートする。図６の例では、メインメニュー画面が全てのテストシナリオの起点である。すなわち、監視対象プログラムがメインメニューを表示した状態では、全てのテストシナリオに該当する状態となり、全てのオブザーバが活性状態となる。
　利用者が行った操作は、まず、監視対象プログラムに対して入力される。監視対象プログラムのコードには、入力操作を取得する関数とともにジョインポイントが定義されており、利用者が入力操作を行うごとにアスペクトが実行される。アスペクトには、入力操作を取得してオブザーバへ送信する処理が記述されており、これにより、入力された操作が全てのオブザーバへ送信される。
　例えば、「メニュー遷移操作１」が行われると、当該操作が全てのオブザーバへ送信される。この操作は、テストシナリオ１～３のみに該当する操作であるため、テストシナリオ１～３に対応するオブザーバのみが活性状態となり、他のオブザーバは非活性状態となる。このように、操作が進むにつれて活性状態のオブザーバが減っていく。そして、再度起点であるメインメニューに戻ると、全てのオブザーバが活性状態に戻る。このように、利用者の操作によって、各オブザーバの活性状態と非活性状態が随時切り替わる。
　例えば、メインメニューから以下の操作を順に行った場合の、活性状態にあるオブザーバの一覧は以下の通りである。なお、ここでは説明の便宜上、例示したテストシナリオ１～６に対応するオブザーバを、それぞれオブザーバ１～６と称する。
（１）初期状態（メインメニュー）：オブザーバ１，２，３，４，５，６
（２）メニュー遷移操作１：オブザーバ１，２，３
（３）操作Ａ：オブザーバ１，２，３
（４）操作Ｆ：オブザーバ３
（５）操作Ｇ：オブザーバ３
（６）操作Ｚ：オブザーバ１，２，３，４，５，６
　本例では、メインメニューが各テストシナリオの起点であるため、操作Ｚを行うことによって、全てのオブザーバが活性状態に戻っている。
　本実施形態に係る監視プログラム３１は、オブザーバの活性状態に基づいて、監視対象プログラム３２が検証済みの状態であるか否かを判定することができる。車載端末１００上で動作する監視プログラム３１が行う監視処理を、図８のフローチャートで示す。車載端末１００上で実行プログラム３０が開始されると、図８のフローチャートが開始される。
　まず、ステップＳ２１で、利用者が入力操作を行うごとに、全てのオブザーバが当該入力操作を取得する。次に、ステップＳ２２およびＳ２３で、各オブザーバが、ステップＳ２１で取得した操作と、自己が有するテストシナリオとを比較する。この結果、自オブザーバが活性化の対象であった場合、活性状態に切り替え（Ｓ２２）、非活性化の対象であった場合、非活性状態に切り替える（Ｓ２３）。非活性状態となったオブザーバは、マスタオブザーバ３１Ｍに対して非活性化した旨を通知する。
　ステップＳ２４は、全てのオブザーバが非活性状態であることを検出するステップである。具体的には、マスタオブザーバ３１Ｍが、活性状態にあるオブザーバの数を計数する。ここで、活性状態にあるオブザーバが一つもなかった場合は、テストシナリオに無い操作が行われていることを意味するため、ステップＳ２５に遷移し、マスタオブザーバ３１Ｍがユーザフェールというイベントを発生させる。ユーザフェールとは、プログラムが未検証状態となったことを通知するイベントである。例えば、車両を制御するシステムがユーザフェール状態となった場合、システムを、運転に必要最低限な構成であるセーフモードに移行することが考えられる。また、比較的安全と考えられる状況であった場合、運転者に対する通知のみを行ってもよい。
　ユーザフェールが発生すると、マスタオブザーバ３１Ｍは、異常を通知するための外部プログラムを起動し、当該外部プログラムが、ＬＥＤやＬＣＤなどのディスプレイ（非図示）を通じて、運転者に異常が発生した旨を通知する。また、ディスク装置１０５に、関連する情報をログとして記録する。記録する情報は、プログラムのメモリダンプや、利用者が行った操作のログなどである。なお、これらのログ情報は、通信装置１０４を通して管理センター２００に送信してもよい。また、異常が発生した旨の通知は、監視対象プログラムに対して行ってもよい。
　なお、活性状態にあるオブザーバが一つ以上ある場合は、処理はステップＳ２１へ遷移し、再度入力操作を待つ。
　本実施形態によれば、コンピュータ上で実行されるオブザーバが、監視対象プログラムに対する入力を監視することにより、テストされていないパターンの入力操作が利用者によってされたことを検出することができる。これにより、システムがクリティカルな状態になる前に通知することができ、システムの安全性を高めることができる。
　なお、第一の実施形態では、オブザーバが全て非活性状態となった場合に、マスタオブザーバがユーザフェールを発生させたが、オブザーバの活性状態をチェックする別のプログラムを設け、全てのオブザーバが非活性状態となった場合、当該プログラムがユーザフェールを発生させてもよい。
　また、第一の実施形態では、ユーザフェールが発生した場合、必要な処理を行ったのちに動作を終了しているが、ユーザフェールが発生した後に再度オブザーバが活性化した場合は、回復処理を行ったのちに監視を継続するようにしてもよい。回復処理とは、再度検証済みの状態になったことを外部に通知する処理であってもよいし、システムのモードをセーフモードから通常モードに復帰させる処理などであってもよい。
　また、本実施形態では、メインメニューを各テストシナリオの起点とし、画面がメインメニューに遷移した際に全オブザーバの活性化を行っているが、オブザーバ活性化のタイミングは、テストシナリオに応じて任意のタイミングとすることができる。例えば、サブメニューに遷移した際に活性化されるオブザーバがあってもよいし、任意の条件を満たした場合に活性化されるオブザーバがあってもよい。
　また、対象とする言語はＪａｖａ以外であってもよい。アスペクト指向のフレームワークが使用できれば、例えばＣ言語やＣ＋＋、ＰＨＰなどであってもよいし、監視対象プログラムに対する入力操作を何らかの方法によってオブザーバに通知することができれば、アスペクト指向プログラミングを使用しなくてもよい。例えば、BTC Embedded Systems AG社による開発ツールであるEmbeddedTesterを使用すれば、Ｃ言語で生成したオブザーバおよびプログラムを互いに接続し、プログラムの監視を実行することができる。
（第二の実施形態）
　第二の実施形態は、監視対象のプログラムと、オブザーバとが独立したハードウェア上にて動作する形態である。図９は、第二の実施形態に係る回路構成を表した図である。
　本実施形態では、第一の実施形態と同様に、ソフトウェア作成装置によってプログラムの生成を行うが、以下の点において第一の実施形態と相違する。
　具体的には、コード生成部２３およびオブザーバ生成部２４で生成されるコードがＪａｖａではなく、ＡＨＤＬやＶＨＤＬなどのハードウェア記述言語である。また、コード合成部２５でのコードの合成は行われず、監視対象プログラムおよびオブザーバが別個にビルドされる。また、コード書込部２６では、監視対象プログラムおよびオブザーバがそれぞれ集積回路等のデジタル回路に別個に書き込まれる。
　ソフトウェアの開発手順は、図４に示したフローチャートと同様である。
　図９は、監視対象プログラムが書き込まれた監視対象回路４１と、複数のオブザーバが書き込まれたオブザーバ回路４２との関係を表した図である。監視対象回路４１は、監視対象となるプログラム、すなわち第一の実施形態における監視対象プログラム３２が実行される回路である。また、オブザーバ回路４２は、監視を行うプログラム、すなわち第一の実施形態におけるマスタオブザーバ３１Ｍ、および複数のオブザーバ（３１Ａ，３１Ｂ、３１Ｃ…）が実行される回路である。本実施形態では、オブザーバ回路４２は、ユーザインタフェースから監視対象回路４１に入力される操作信号を、入力信号線を経由して取得し、図８に示した処理を行う。ユーザフェール処理が発生した場合、異常信号線を通して外部への異常通報を行う。
　異常通報がなされた場合、システムを制御する回路がこれを取得し、第一の実施形態と同様の対応をとることができる。例えば、利用者に通知を行ってもよいし、システムの一部を制限したモードに移行してもよい。また、該当する回路をシステムから切り離してもよい。
　本実施形態によると、コンピュータ上ではなく、集積回路上で動作するプログラムにも、本発明を適用することができる。第一の実施形態が、同一のコンピュータ上で動作するのに対し、本実施形態ではオブザーバを別個の集積回路に書き込んでいるため、監視対象システムが動作する回路と、オブザーバが動作する回路とを分離して設計することができるという利点を有している。
（変形例）
　なお、各実施形態の説明は本発明を説明する上での例示であり、本発明は、発明の趣旨を逸脱しない範囲で適宜変更または組み合わせて実施することができる。例えば、複数の実施形態を組み合わせてもよいし、仕様外の動作を検出した場合、第一の実施形態にて例示していない方法によって利用者への通知を行ってもよい。
　また、実施形態の説明では、利用者が何らかの入力操作を行うごとにオブザーバの活性化および非活性化を行ったが、テストシナリオと関係のない入力操作についてはステップＳ２１で受け捨てるようにしてもよい。例えば、キーボードからの入力がなされた場合であり、当該入力がテキストボックスに対して行われているものであった場合は、入力確定ボタンが押されるまでステップＳ２１で処理を止め、待機するようにしてもよい。
　また、実施形態の説明では、クリックやタップなど、プログラムの状態を遷移させるための単純な入力を入力操作として例示したが、入力操作は、入力値を伴うものであってもよい。例えば、テストシナリオに定義された操作が「１０文字以内で文字列を入力」であって、１１文字以上が入力された場合は、テストシナリオに該当しないものとしてオブザーバを非活性化してもよい。このように、テストシナリオに記録される入力操作は、利用者による操作と関連付いたものであれば、どのようなものが定義されてもよい。
　また、本発明は、利用者による入力操作に基づいて検証状態／未検証状態の判定を行うものであるが、外部からの入力データに基づいてテストシナリオとの一致を判定する機能を追加してもよいし、システム内部で発生するデータに基づいてテストシナリオとの一致を判定する機能を追加してもよい。このように、テストシナリオと実際の動作とを比較するものであれば、様々なものに応用することができる。
　１０　ソフトウェア要件
　１１　テストシナリオ
　１２　シーケンスダイアグラム
　１３　ステートチャート
　１４　オブザーバコード
　１５　アプリケーションコード
　２１　ソフトウェア要件記憶部
　２２　テストシナリオ生成部
　２３　オブザーバ生成部
　２４　ソフトウェアモデル生成部
　２５　コード生成部
　２６　コード書込部
　１００　車載端末
　１０１　演算処理装置
　１０２　記憶装置
　１０３　入力装置
　１０４　通信装置
　１０５　ディスク装置
　２００　管理センター

Claims (12)

  1. 　入力操作を取得する入力手段と、
    　前記入力手段が取得した入力操作をもとに演算を行う演算プログラムが実行される第一のプログラム実行手段と、
    　前記演算プログラムに対する複数のテストシナリオを記憶したテストシナリオ記憶手段と、
    　前記入力手段が取得した入力操作が、前記記憶された複数のテストシナリオのうち、いずれかと対応するものであるかを判定する監視プログラムが実行される第二のプログラム実行手段と、を有するコンピュータ。
  2. 　前記各テストシナリオは、複数の入力操作の内容および順序をそれぞれ含む、
    　請求項１に記載のコンピュータ。
  3. 　前記監視プログラムは、前記入力手段から複数の入力操作を取得し、前記取得した複数の入力操作が、いずれかのテストシナリオに含まれる入力操作の内容および順序と一致した場合に、前記取得した入力操作が、当該テストシナリオに対応するものであると判定する、
    　請求項２に記載のコンピュータ。
  4. 　前記監視プログラムは、前記取得した入力操作が、記憶された複数のテストシナリオのいずれとも対応しない場合に、前記演算プログラムまたは外部プログラムに対して、システムが未検証状態である旨を通知する、
    　請求項１から３のいずれかに記載のコンピュータ。
  5. 　演算を行う演算プログラムと同時に実行され、前記演算プログラムに対する入力操作を監視する監視プログラムであって、
    　前記演算プログラムに対する入力操作を取得する入力取得ステップと、
    　前記取得した入力操作が、事前に記憶された、前記演算プログラムに対する複数のテストシナリオのうちいずれかと対応するものであるかを判定する入力判定ステップと、を含む、
    　監視プログラム。
  6. 　前記記憶された各テストシナリオは、複数の入力操作の内容および順序をそれぞれ含む、
    　請求項５に記載の監視プログラム。
  7. 　前記入力取得ステップは、複数の入力操作を取得し、
    　前記入力判定ステップは、前記取得した複数の入力操作が、いずれかのテストシナリオに含まれる入力操作の内容および順序と一致した場合に、前記取得した入力操作が、当該テストシナリオに対応するものであると判定する
    　請求項６に記載の監視プログラム。
  8. 　前記入力判定ステップにおいて、前記取得した入力操作が、記憶された複数のテストシナリオのいずれとも対応しない場合に、前記演算プログラムまたは外部プログラムに対して、システムが未検証状態である旨を通知するステップを実行する、
    　請求項５から７のいずれかに記載の監視プログラム。
  9. 　演算を行う演算プログラムと、前記演算プログラムに対する入力操作を監視する監視プログラムと、
    　を生成するソフトウェア作成装置であって、
    　前記演算プログラムのコード入力を受け付ける演算プログラム入力手段と、
    　モデリング言語によって記述された、前記演算プログラムに対する複数のテストシナリオの入力を受け付けるテストシナリオ入力手段と、
    　前記演算プログラムを生成する演算プログラム生成手段と、
    　前記複数のテストシナリオを含み、前記演算プログラムに対する入力操作が、前記複数のテストシナリオのうちいずれかと対応するものであるかを判定する監視プログラムを生成する監視プログラム生成手段と、
    　前記演算プログラムと、監視プログラムを実行用コンピュータに記録するプログラム書き込み手段と、
    　を有し、
    　前記演算プログラム生成手段は、前記演算プログラムに対し、前記演算プログラムが行う所定の処理をトリガとして、前記演算プログラムに対して行われた入力操作を前記監視プログラムに通知する処理を追加する、
    　ソフトウェア作成装置。
  10. 　前記各テストシナリオは、複数の入力操作の内容および順序をそれぞれ含む、
    　請求項９に記載のソフトウェア作成装置。
  11. 　前記監視プログラムは、複数の入力操作を取得し、前記取得した複数の入力操作が、いずれかのテストシナリオに含まれる入力操作の内容および順序と一致した場合に、前記取得した入力操作が、当該テストシナリオに対応するものであると判定する、
    　請求項１０に記載のソフトウェア作成装置。
  12. 　前記監視プログラムは、前記取得した入力操作が、複数のテストシナリオのいずれとも対応しない場合に、前記演算プログラムまたは外部プログラムに対して、システムが未検証状態である旨を通知可能である、
    　請求項９から１１のいずれかに記載のソフトウェア作成装置。
PCT/JP2013/072439 2012-08-23 2013-08-22 自己監視機能を備えたコンピュータ、監視プログラム WO2014030707A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201380044043.3A CN104583969B (zh) 2012-08-23 2013-08-22 具备自监视功能的计算机、监视方法
US14/423,309 US9588878B2 (en) 2012-08-23 2013-08-22 Computer having self-monitoring function and monitoring program
EP13830967.9A EP2889775B1 (en) 2012-08-23 2013-08-22 Computer having self-monitoring function and monitoring program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2012184540A JP5714543B2 (ja) 2012-08-23 2012-08-23 自己監視機能を備えたコンピュータ、監視プログラム
JP2012-184540 2012-08-23

Publications (1)

Publication Number Publication Date
WO2014030707A1 true WO2014030707A1 (ja) 2014-02-27

Family

ID=50150011

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/072439 WO2014030707A1 (ja) 2012-08-23 2013-08-22 自己監視機能を備えたコンピュータ、監視プログラム

Country Status (5)

Country Link
US (1) US9588878B2 (ja)
EP (1) EP2889775B1 (ja)
JP (1) JP5714543B2 (ja)
CN (1) CN104583969B (ja)
WO (1) WO2014030707A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106406276A (zh) * 2015-07-29 2017-02-15 罗伯特·博世有限公司 用于在控制设备中进行车载诊断的方法和设备

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9400737B2 (en) * 2014-08-07 2016-07-26 International Business Machines Corporation Generation of automated unit tests for a controller layer system and method
GB2533117A (en) * 2014-12-10 2016-06-15 Ibm Software test automation
US10546279B2 (en) * 2016-06-27 2020-01-28 International Business Machines Corporation Scenario based logging
CN107643979A (zh) * 2017-08-10 2018-01-30 浙江浙大列车智能化工程技术研究中心有限公司 一种提高系统安全性的方法
US10809741B2 (en) 2017-11-17 2020-10-20 Polaris Industries Inc. Method and system for controlling the speed of a vehicle
US10860298B2 (en) * 2018-03-21 2020-12-08 Dspace Digital Signal Processing And Control Engineering Gmbh Method and system for editing a block diagram model
US10417115B1 (en) * 2018-04-27 2019-09-17 Amdocs Development Limited System, method, and computer program for performing production driven testing
US10691584B2 (en) * 2018-09-28 2020-06-23 Sap Se Behavior driven development integration with test tool

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001022717A (ja) * 1999-07-12 2001-01-26 Hitachi Ltd 分散環境の運用管理システムに関する誤操作判別方法
JP2008049888A (ja) * 2006-08-25 2008-03-06 Denso Corp 走行制御装置
JP2009151420A (ja) * 2007-12-19 2009-07-09 Toyota Central R&D Labs Inc ソフトウェア動作監視装置、プログラム

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5724504A (en) * 1995-06-01 1998-03-03 International Business Machines Corporation Method for measuring architectural test coverage for design verification and building conformal test
US5784553A (en) * 1996-01-16 1998-07-21 Parasoft Corporation Method and system for generating a computer program test suite using dynamic symbolic execution of JAVA programs
JP2002268729A (ja) 2001-03-14 2002-09-20 Toshiba Syst Technol Corp ソフトアイソレーション装置
US6694235B2 (en) 2001-07-06 2004-02-17 Denso Corporation Vehicular relay device, in-vehicle communication system, failure diagnostic system, vehicle management device, server device and detection and diagnostic program
JP4622177B2 (ja) 2001-07-06 2011-02-02 株式会社デンソー 故障診断システム、車両管理装置、サーバ装置、及び検査診断プログラム
JP2003122599A (ja) * 2001-10-11 2003-04-25 Hitachi Ltd 計算機システムおよび計算機システムにおけるプログラム実行監視方法
JP4913353B2 (ja) * 2005-03-25 2012-04-11 株式会社エヌ・ティ・ティ・ドコモ ソフトウェア動作モデル化装置及びソフトウェア動作監視装置
CN100401265C (zh) * 2005-06-06 2008-07-09 华为技术有限公司 关键字驱动的自动化测试系统及方法
US7493522B2 (en) * 2006-01-30 2009-02-17 Microsoft Corporation Model independent input reduction
WO2007091297A1 (ja) * 2006-02-06 2007-08-16 Fujitsu Limited 情報処理装置、ｃｐｕ、診断プログラムおよび診断方法
JP4331186B2 (ja) * 2006-07-13 2009-09-16 株式会社東芝 モデル検査用情報生成装置およびプログラム
US7779374B1 (en) * 2006-09-29 2010-08-17 Breker Verification Systems, Inc. Generating self-checking test cases from reduced case analysis graphs
JP2008179314A (ja) * 2007-01-26 2008-08-07 Denso Corp 車両診断システム
US8140986B2 (en) * 2007-09-27 2012-03-20 International Business Machines Corporation Generating test scenarios using reusable triggers indicating graphical user interface (GUI) elements and actions
US20100192128A1 (en) * 2009-01-27 2010-07-29 Honeywell International Inc. System and methods of using test points and signal overrides in requirements-based test generation
KR101337014B1 (ko) * 2011-07-12 2013-12-05 주식회사 팬택 이동 단말기, 이를 이용하는 차량의 ｅｃｕ 제어 시스템 및 방법
JP5680514B2 (ja) 2011-09-29 2015-03-04 トヨタ自動車株式会社 自己診断機能を備えたコンピュータ、ソフトウェア作成方法、およびソフトウェア作成装置
MX343133B (es) * 2012-03-09 2016-10-25 Honda Motor Co Ltd Sistema de simulacion de comunicacion, metodo de simulacion de comunicacion, y aparato de comunicacion del vehiculo.

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001022717A (ja) * 1999-07-12 2001-01-26 Hitachi Ltd 分散環境の運用管理システムに関する誤操作判別方法
JP2008049888A (ja) * 2006-08-25 2008-03-06 Denso Corp 走行制御装置
JP2009151420A (ja) * 2007-12-19 2009-07-09 Toyota Central R&D Labs Inc ソフトウェア動作監視装置、プログラム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"ODB-II On-Board Diagnostics", B&B ELECTRONICS, 23 July 2012 (2012-07-23)
See also references of EP2889775A4

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106406276A (zh) * 2015-07-29 2017-02-15 罗伯特·博世有限公司 用于在控制设备中进行车载诊断的方法和设备
CN106406276B (zh) * 2015-07-29 2021-07-27 罗伯特·博世有限公司 用于在控制设备中进行车载诊断的方法和设备

Also Published As

Publication number Publication date
US20150261660A1 (en) 2015-09-17
US9588878B2 (en) 2017-03-07
EP2889775A4 (en) 2015-09-23
CN104583969B (zh) 2018-05-18
EP2889775B1 (en) 2019-12-11
CN104583969A (zh) 2015-04-29
EP2889775A1 (en) 2015-07-01
JP5714543B2 (ja) 2015-05-07
JP2014041554A (ja) 2014-03-06

Similar Documents

Publication Publication Date Title
JP5714543B2 (ja) 自己監視機能を備えたコンピュータ、監視プログラム
US10949338B1 (en) Automated software bug discovery and assessment
JP7202448B2 (ja) 安全性が要求されるプロセスを監視する自動化システム
JP5680514B2 (ja) 自己診断機能を備えたコンピュータ、ソフトウェア作成方法、およびソフトウェア作成装置
Arcaini et al. The ASMETA approach to safety assurance of software systems
Denil et al. DEVS for AUTOSAR-based system deployment modeling and simulation
Wu et al. A modeling methodology to facilitate safety‐oriented architecture design of industrial avionics software
Pop et al. Methods and tools for reducing certification costs of mixed-criticality applications on multi-core platforms: the RECOMP approach
JP2010015240A (ja) 検証システム及び検証装置
Hussein et al. Safe adaptation of vehicle software systems
US11650585B1 (en) Fault tolerant autonomous vehicle platform
Ghadhab et al. A controller safety concept based on software-implemented fault tolerance for fail-operational automotive applications
Beato et al. UML automatic verification tool (TABU)
Wu et al. Ensuring safety of avionics software at the architecture design level: An industrial case study
Drabek et al. DANA-Description and Analysis of Networked Applications.
JP7267400B2 (ja) 安全性が要求されるプロセスを監視する自動化システム
Fu et al. A formally verified fail-operational safety concept for automated driving
Drabek et al. Interface Verification Using Executable Reference Models: An Application in the Automotive Infotainment.
Fu Fault injection mechanisms for validating dependability of automotive systems
Paulitsch et al. Non-functional avionics requirements
Akhtar Model based automotive system design: A power window controller case study
Drabek et al. Reducing the verification effort for interfaces of automotive infotainment software
Da Silva et al. Using Runtime Information of Controllers for Safe Adaptation at Runtime: A Process Mining Approach
Belli et al. A graph-model-based testing method compared with the classification tree method for test case generation
Abel et al. Development and verification of complex hybrid systems using synthesizable monitors

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13830967

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 14423309

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2013830967

Country of ref document: EP