JP7842269B2 - 情報処理方法および情報処理装置 - Google Patents

Description

本開示は、アクチュエータ及び／又は加熱器を備える装置の制御プログラムを生成するための情報処理方法などに関する。

従来、家庭用電化製品及び住宅設備等は、その製造者等によって予め用意された運転条件（制御プログラム）に従って制御される。特許文献１には、ユーザが実施したい洗濯の運転条件を設定可能な洗濯機が開示されている。

特開２００３－２８４８８９号公報

しかしながら、上記従来技術では、製品の製造者等によって予め開発された制御プログラムが製品に予め格納されていなければならず、多様でかつ安全な制御プログラムを生成してカスタマイズ及びアップデートすることは難しい。

そこで、本開示は、多種多彩でかつ安全な制御プログラムを簡単に生成することができる情報処理方法などを提供する。

本開示の一態様に係る情報処理方法は、コンピュータシステムによって実行される情報処理方法であって、（ａ）制御対象機器に備えられているアクチュエータ及び加熱器の少なくとも１つを駆動するためのＭ個（Ｍは１以上の整数）のブロックのそれぞれが実行される順番を、操作者による入力操作に応じて設定することで、前記Ｍ個のブロックを含むアプリケーションを生成し、（ｂ）所定の２以上のブロックの１つが実行される場合に前記所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止するルールを参照して、前記アプリケーションに含まれる前記Ｍ個の選択ブロックが前記ルールに該当する場合、前記操作者に対してエラーを提示する。

また、本開示の一態様に係る情報処理方法は、コンピュータシステムによって実行される情報処理方法であって、（ａ）制御対象機器に備えられているアクチュエータ及び加熱器の少なくとも１つを駆動するためのＮ個（Ｎは２以上の整数）のブロックから、操作者による入力操作に応じて、Ｍ個（Ｍは１以上かつＮ以下の整数）のブロックのそれぞれを選択ブロックとして選択し、（ｂ）少なくとも前記Ｍ個の選択ブロックのそれぞれが実行される順番を、前記操作者による入力操作に応じて設定することで、少なくとも前記Ｍ個の選択ブロックを含むアプリケーションを生成し、（ｃ）所定の２以上のブロックの１つが実行される場合に前記所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止するルールを参照して、前記アプリケーションに含まれる前記Ｍ個の選択ブロックが前記ルールに該当する場合、前記アプリケーションを変更し、（ｄ）前記変更したアプリケーションを出力する。

なお、これらの包括的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。

本開示の一態様に係る情報処理方法は、多種多彩でかつ安全な制御プログラムを簡単に生成することができる。

図１は、実施の形態１におけるシステムのハードウェア構成図である。 図２Ａは、実施の形態１におけるクラウドサーバのハードウェア構成図である。 図２Ｂは、実施の形態１における装置のハードウェア構成図である。 図２Ｃは、実施の形態１における端末のハードウェア構成図である。 図３は、実施の形態１におけるシステムの機能構成図である。 図４は、実施の形態１におけるアプリケーションを規定するブロックの一例を示す。 図５は、実施の形態１における洗濯機のための複数のブロックを示す。 図６は、実施の形態１における電子レンジのための複数のブロックを示す。 図７は、実施の形態１における炊飯器のための複数のブロックを示す。 図８は、実施の形態１におけるシステムのシーケンス図である。 図９は、実施の形態１におけるデバイスデータベースの一例を示す。 図１０は、実施の形態１における実行内容宣言の一例を示す。 図１１は、実施の形態１における実行前確認処理のフローチャートを示す。 図１２は、実施の形態１におけるルールデータベースの一例を示す。 図１３は、実施の形態１におけるアプリケーションの変更の一例を示す。 図１４は、実施の形態１におけるアプリケーションの変更の一例を示す。 図１５Ａは、実施の形態１の変形例１におけるシステムのシーケンス図である。 図１５Ｂは、実施の形態１の変形例２におけるシステムのシーケンス図である。 図１５Ｃは、実施の形態１の変形例３におけるシステムのシーケンス図である。 図１５Ｄは、実施の形態１の変形例４におけるシステムのシーケンス図である。 図１５Ｅは、実施の形態１の変形例５におけるシステムのシーケンス図である。 図１６は、実施の形態２における実行前確認処理のフローチャートを示す。 図１７は、実施の形態３における実行前確認処理のフローチャートを示す。 図１８は、実施の形態４における実行前確認処理のフローチャートを示す。 図１９は、実施の形態５における情報処理システムの構成例を示す図である。 図２０は、実施の形態５におけるブロックデータベースおよびルールデータベースのそれぞれに格納されている情報の一例を示す図である。 図２１は、実施の形態５におけるルールデータベースに含まれる汎用ルールの一例を示す図である。 図２２は、実施の形態５における情報処理システムのシーケンス図である。 図２３は、実施の形態５における開発ツールの全体的な処理動作を示すフローチャートである。 図２４は、実施の形態５における配置の自動修正処理の一例を示すフローチャートである。 図２５は、実施の形態５における配置のエラー提示処理の一例を示すフローチャートである。 図２６は、実施の形態５におけるシーケンス生成画面の一例を示す図である。 図２７は、実施の形態５におけるブロック一覧の表示例を示す図である。 図２８Ａは、実施の形態５における機能ブロックの配置処理と、配置の自動修正処理の一例を示す図である。 図２８Ｂは、実施の形態５における機能ブロックの配置処理と、配置の自動修正処理の他の例を示す図である。 図２９は、実施の形態５における配置のエラー提示処理の一例を示す図である。 図３０は、実施の形態５における接続のエラー提示処理の他の例を示す図である。 図３１は、実施の形態５における対処法の他の提示例を示す図である。 図３２は、実施の形態５における対処法のさらに他の提示例を示す図である。 図３３は、実施の形態５の変形例における開発ツールの処理動作を示すフローチャートである。

（本開示の基礎となった知見）
本願発明者らが本開示に至るまでの経緯を説明する。アクチュエータ及び／又は加熱器を有する家庭用電化製品等において、多様なユーザの望みに合わせて制御プログラムを開発するためには、開発環境のオープン化が求められる。すなわち、制御プログラムの開発の難度を低下させて、サードパーティが制御プログラムの開発に容易に参加できる環境が求められる。このような環境では、例えば、アパレル企業が、自社の販売する衣服を洗濯するための洗濯機の制御プログラムを開発することも可能となる。

そこで、本発明者らは、製品に含まれるアクチュエータ及び／又は加熱器の制御を抽象化した機能ブロックを用いて、安全面の担保を維持しながら、制御プログラムを開発可能な環境を構築し、複数の機能ブロックの組み合わせからなる制御プログラムをパッケージ化してアプリケーションとして配信可能な仕組みを検討した。これにより、多種多彩なアプリケーションの配信が可能となり、より多様なユーザの望みに応えて製品をカスタマイズ及びアップデートすることが可能となる。しかしながら、このような環境では、危険なアプリケーション（つまり、製品を安全に制御することができないアプリケーション）が配信される可能性があり、製品の安全性が低下する。

例えば、家庭用電化製品等に含まれるプログラムは、アクチュエータ及び／又は加熱器を直接制御するための機器に組込まれ、かつ、製造者により開発されたプログラムと、サードパーティにより開発されたプログラムとを互いに入り交じった状態で含むことが想定される。このとき、製造者は、サードパーティに、ノウハウを含む全ての家庭用電化製品等の情報を公開しない可能性が高い。例えば、アクチュエータ及び／又は加熱器を駆動するパラメータ又はタイミングは、製造者の家庭用電化製品等の性能に関わるノウハウである。よって、競争力の低下につながる恐れがあるため、製造者は、サードパーティに、家庭用電化製品等を自在に駆動できるようにノウハウをオープンにする可能性は低い。

そのため、サードパーティは、家庭用電化製品等の情報不足により、製造者が想定しない制御の組み合わせ、又はパラメータ範囲を含むアプリケーション、すなわち、安全性が担保されないアプリケーションを作成する可能性がある。このようなアプリケーションがユーザに提供されることは、ユーザに望ましくない。

また、家庭用電化製品等の製造者は、新たな制御プログラムを提供することで、ユーザのくらしのアップデートを試みることが考えられる。しかしながら、多種多様な新たな制御プログラムの開発には、パラメータの調整、またはハードの性能評価などの膨大な工数がかかる。家庭用電化製品等は、アクチュエータ及び／又は加熱器のハードが物理的に駆動するため、家庭用電化製品等のプログラムは、スマートフォンのプログラムと比較して、性能評価などの工数が大きくなることが容易に予想される。しかし、大量生産ではなく、ユーザ一人一人の生活に応じたオンデマンド開発が求められる時代において、スマートフォンのプログラムと同様に、家庭用電化製品等の多種多様な制御プログラム開発することが求められる。そのため、製造者は、膨大な工数を低減した上で、製品の安全性を担保する多種多様なアプリケーションを作成しなければならない。

さらに、製造者は、サードパーティが提供するアプリケーションを用いて家庭用電化製品等が動作した場合でも、安全に動作することを保証することを望むことが考えられる。このとき、多種多様なアプリケーションを家庭用電化製品等で実際に駆動させて安全性を検証する作業の量を低減することが望まれる。

そこで、本開示は、アクチュエータ及び／又は加熱器を駆動する複数の機能ブロックで規定された多種多彩なアプリケーションを、より簡単かつ安全に実行することができる装置等を提供する。

以下、実施の形態について、図面を参照しながら具体的に説明する。

なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、請求の範囲を限定する主旨ではない。

また、各図は、必ずしも厳密に図示したものではない。各図において、実質的に同一の構成については同一の符号を付し、重複する説明は省略又は簡略化する。

（実施の形態１）
［１．１ ハードウェア構成］
本実施の形態におけるシステム１のハードウェア構成について、図１～図２Ｃを参照しながら説明する。図１は、実施の形態１におけるシステム１のハードウェア構成図である。図２Ａは、実施の形態１におけるクラウドサーバ１０のハードウェア構成図である。図２Ｂは、実施の形態１における装置２０のハードウェア構成図である。図２Ｃは、実施の形態１における端末３０のハードウェア構成図である。

図１に示すように、本実施の形態におけるシステム１は、クラウドサーバ１０と、施設２ａ～２ｄで用いられる装置２０ａ～２０ｈと、端末３０ａ～３０ｄと、を備える。施設２ａ～２ｄは、例えば住宅であるが、これに限定されない。施設２ａ～２ｄは、例えばマンション、店舗、オフィス等であってもよい。

クラウドサーバ１０は、コンピュータネットワーク（例えばインターネット）を介して提供される仮想的なサーバである。クラウドサーバ１０は、コンピュータネットワークを介して、装置２０ａ～２０ｈ及び端末３０ａ～３０ｄに接続される。なお、クラウドサーバ１０の代わりに物理サーバが用いられてもよい。

図２Ａに示すように、クラウドサーバ１０は、仮想的に、プロセッサ１１と、プロセッサ１１に接続されたメモリ１２と、を備える。プロセッサ１１は、メモリ１２に格納されたインストラクション又はソフトウェアプログラムが実行されたときに、後述するシーケンスマネージャ及びデバイスマネージャとして機能する。

装置２０ａ～２０ｈは、施設２ａ～２ｄで利用される電気機械器具である。なお、図１では、施設２ｂ～２ｄで利用される装置２０ｃ～２０ｈの図示が省略されている。以下において、装置２０ａ～２０ｈの区別が不要な場合には装置２０と記載する。

装置２０としては、家庭用電化製品（家電）及び住宅設備等を用いることができる。家庭用電化製品（家電）及び住宅設備等は、住宅内で使用される機器に限られず、事業に用いられる機器も含む。なお、本開示では、家庭用電化製品及び住宅設備等を家庭用電化製品等と省略して記載することがある。家電としては、例えば、電子レンジ、炊飯器、ミキサー（Blender）、電気オーブン、電気トースター、電気ポット、ホットプレート、ＩＨ（Induction heating）調理器、ロースター、ベーカリー、電気圧力調理なべ、電気無水調理なべ、マルチクッカー、コーヒーメーカー、冷蔵庫、洗濯機、食洗器、掃除機、エアコン、空気清浄機、加湿器、ドライヤー、扇風機、及びイオン発生器等が用いられる。住宅設備としては、例えば、電動シャッター、電子ロック、及び浴槽用の電気湯沸し器等が用いられる。なお、装置２０は、これに限定されない。

図２Ｂに示すように、装置２０は、筐体２１と、アクチュエータ２２と、加熱器２３と、制御部２４と、を備える。なお、装置２０は、アクチュエータ２２及び加熱器２３の少なくとも１つを備えればよく、アクチュエータ２２及び加熱器２３の両方を備えなくてもよい。

筐体２１は、アクチュエータ２２と、加熱器２３と、制御部２４と、を収容する。また、筐体２１は、対象物を処理するための内部空間を有してもよい。例えば、洗濯機の洗濯槽、電子レンジの加熱室、及び炊飯器の内釜等が、対象物を処理するための内部空間に相当する。

アクチュエータ２２は、電気信号に基づいて入力エネルギーを物理的運動に変換する機械要素である。アクチュエータ２２としては、例えば電気モータ、油圧シリンダ及び空気圧アクチュエータ等を用いることができるが、これらに限定されない。

加熱器２３は、電気エネルギーを熱エネルギーに変換する電気加熱器である。加熱器２３は、例えばジュール加熱、誘導加熱及び誘電加熱等により対象物を加熱する。加熱器２３としては、例えば、ニクロム線、コイル及びマグネトロン等を用いることができる。

ここで、本開示の装置２０が、アクチュエータ２２及び／又は加熱器２３を備える理由の一例を説明する。家庭用電化製品等の製造者が、アクチュエータ２２及び加熱器２３を駆動するパラメータ、駆動の組み合わせを全て自由に制御可能な開発環境をサードパーティに提供した場合を考える。このとき、サードパーティは、製造者が想定しているアクチュエータ２２及び／又は加熱器２３を安全に駆動できるパラメータ範囲、又はアクチュエータ２２及び／又は加熱器２３の駆動制限を逸脱して制御するプログラムを作成することが可能になる。特に、物理的に運動するアクチュエータ２２、又は熱エネルギーを出力する加熱器２３の、製造者の想定していない駆動は、安全性の担保の課題が大きい。製造者の想定していない駆動としては、例えば、アクチュエータの一例である電気モータの高速回転、及び、加熱器２３への過電流の供給が挙げられる。本願発明者らは、過度に安全面を考慮することで、ユーザに多種多様なアプリケーションを提供できる環境の構築を阻害しないことを目指した。そこで、物理的に運動するアクチュエータ２２、又は熱エネルギーを出力する加熱器２３に特化して、安全面を担保することを想定し、本開示の装置２０を対象としている。

制御部２４は、アクチュエータ２２及び／又は加熱器２３を制御するコントローラであり、後述するデバイスとして機能する。制御部２４は、例えば、集積回路で構成される。

端末３０ａ～３０ｄは、施設２ａ～２ｄでそれぞれ利用され、ユーザインタフェースとして機能する。なお、図１では、施設２ｂ～２ｄで利用される端末３０ｂ～３０ｄの図示が省略されている。以下において、端末３０ａ～３０ｄの区別が不要な場合には端末３０と記載する。

端末３０は、コンピュータネットワークを介してクラウドサーバ１０及び装置２０に接続され、後述するユーザインタフェース（ＵＩ）として機能する。端末３０としては、スマートフォン及びタブレットコンピュータ等の持ち運び可能な情報端末を用いることができる。なお、端末３０は、施設２ａ～２ｄの壁、床又は天井に固定された端末であってもよい。また、端末３０は、装置２０に含まれてもよい。例えば、端末３０は、各装置２０ａ～２０ｈに内蔵されたディスプレイ等を有する表示端末として実現されてもよい。

図２Ｃに示すように、端末３０は、ディスプレイ３１と、入力デバイス３２と、を備える。ディスプレイ３１としては、例えば液晶ディスプレイ及び有機ＥＬディスプレイを用いることができる。入力デバイス３２としては、例えばタッチパネル、キーボード、マウス及び機械式ボタン等を用いることができる。また、入力デバイス３２として、音声入力デバイスが用いられてもよい。ディスプレイ３１と入力デバイス３２とは、タッチスクリーンとして一体で実装されてもよい。または、入力デバイス３２として、ジェスチャー入力デバイスが用いられてもよい。ジェスチャー入力デバイスは、例えば、カメラと認識部とを有する。カメラはジェスチャーを含む画像を撮像し、認識部は画像を用いてジェスチャーを認識する。

［１．２ 機能構成］
次に、本実施の形態におけるシステム１の機能構成について、図３を参照しながら説明する。図３は、実施の形態１におけるシステム１の機能構成図である。

クラウドサーバ１０は、シーケンスマネージャ１００と、デバイスマネージャ２００と、を備える。装置２０ａ～２０ｈは、デバイス３００ａ～３００ｈをそれぞれ備える。端末３０ａ～３０ｄは、ＵＩ４００ａ～４００ｄをそれぞれ備える。

以下において、デバイス３００ａ～３００ｈの区別が不要な場合にはデバイス３００と記載する。また、ＵＩ４００ａ～４００ｄの区別が不要な場合にはＵＩ４００と記載する。

シーケンスマネージャ１００は、複数のアプリケーションを管理している。複数のアプリケーションは、例えばユーザの操作によって、アプリケーション配信プラットフォームからシーケンスマネージャ１００にダウンロードされる。または、アプリケーション配信プラットフォームに含まれるアプリケーションは、シーケンスマネージャ１００にダウンロードされなくてもよい。その場合、シーケンスマネージャ１００のデータベースに、アプリケーション配信プラットフォームに含まれるアプリケーションが紐づけていることを示す情報が記録されてもよい。アプリケーションの詳細については後述する。

デバイスマネージャ２００は、複数の施設２ａ～２ｄ及び各施設２ａ～２ｄで利用されるデバイス３００及びＵＩ４００を管理するためのデータベースを有する。デバイスマネージャ２００は、データベースに、施設２ａ～２ｄに紐づくデバイス情報及びＵＩ情報を記録することにより、デバイス３００及びＵＩ４００を管理する。デバイス情報及びＵＩ情報は、例えば、制御機能及び駆動機能、並びに稼働状況などを含む。例えば、デバイスマネージャ２００は、デバイス３００の稼働状況を管理して、デバイス３００の稼働スケジュールを把握することができる。また、デバイスマネージャ２００は、デバイス３００のログ情報を管理してもよい。

なお、このようなデータベースは、デバイスマネージャ２００の代わりにシーケンスマネージャ１００が有してもよく、シーケンスマネージャ１００及びデバイスマネージャ２００の両方が有してもよい。

デバイス３００は、装置２０の制御機能及び駆動機能を有する。デバイス３００は、デバイスマネージャ２００からの指示に従って装置２０を駆動することができる。

ＵＩ４００は、ユーザに情報を提供し、ユーザから入力を受け付ける。

ここで、アプリケーションについて説明する。本実施の形態では、アプリケーション（以下、略してアプリということもある）とは、アクチュエータ２２及び／又は加熱器２３を駆動する複数の機能ブロック（以下、略してブロック）で規定される制御プログラムを意味する。複数のブロックの各々は、アクチュエータ２２又は加熱器２３を駆動するためのパラメータを含むことができる。具体的には、複数のブロックの各々は、アクチュエータ２２又は加熱器２３の制御を抽象化したものである。なお、アプリケーションは、アクチュエータ２２及び／又は加熱器２３を駆動する複数のブロックに加えて、アクチュエータ２２及び／又は加熱器２３を駆動しないブロックを含んでもよい。アクチュエータ２２及び／又は加熱器２３を駆動しないブロックの一例は、デバイス３００の有するインタフェースを用いた情報表示、デバイス３００の有するブザーを用いた音声出力、デバイス３００の有するランプの点灯または消灯などを含む。また、ブロックは、アクチュエータ２２又は加熱器２３の駆動を開始する条件を含んでもよい。例えば、第１のブロック、第２のブロックを含むアプリケーションを例に説明する。ここで、第１のブロックの実行中に、第２のブロックに切り替える際に、第２のブロックに含まれる開始条件を満たしたときに、第１のブロックから第２のブロックに切り替える。また、ブロックは、開始条件ではなく、終了条件を含んでいてもよい。第１のブロックの実行中に、第２のブロックに切り替える際に、第１のブロックに含まれる終了条件を満たしたときに、第１のブロックから第２のブロックに切り替える。

図４は、実施の形態１におけるアプリケーションを規定するブロックの一例を示す。図４に示すブロック１０００は、洗濯機の攪拌動作を制御するブロックであり、パラメータ１００１～１００６を含む。パラメータ１００１は、攪拌の種類を示す情報（例えば、通常、ダンシング、揺り）を含む。パラメータ１００１は、機能の種類を示すとも言い換えることができる。パラメータ１００２は、ドラムの回転数を示す値を含む。パラメータ１００２は、アクチュエータ２２及び／又は加熱器２３の駆動の強度を示すとも言い換えることができる。パラメータ１００３は、ドラム内への給水量を給水後の水位で示す値を含む。パラメータ１００３は、アクチュエータ２２及び／又は加熱器２３の駆動後の状態を示すとも言い換えることができる。パラメータ１００４は、循環ポンプのオン／オフを示す値を含む。パラメータ１００４は、アクチュエータ２２及び／又は加熱器２３を駆動するか否かを示すとも言い換えることができる。パラメータ１００５は、攪拌間隔を段階的に示す情報（例えば、短、中、長）を含む。パラメータ１００６は、攪拌時間を示す値を含む。

アプリケーションを規定するために、このようなブロックが複数用いられる。例えば、図５～図７に示すような複数のブロックが用いられる。

図５は、実施の形態１における洗濯機のための複数のブロックを示す。図６は、実施の形態１における電子レンジのための複数のブロックを示す。図７は、実施の形態１における炊飯器のための複数のブロックを示す。なお、図５～図７に示す複数のブロックは例示であり、洗濯機、電子レンジ及び炊飯器のためのブロックは、これらに限定されない。例えば、複数のブロックは、抽象化レベルによって階層化されてもよい。

例えば、製造者向けの階層と製造者以外向けの階層とで抽象化レベルを変更してもよい。製造者以外の例は、他の製造者向けの階層、サードパーティ向けの階層である。

この時、製造者向けの階層は、製造者以外向けの階層より抽象度が低い。抽象度が低いことは、アクチュエータ及び加熱器を駆動するパラメータに近い内容が制御されることを意味する。

一方、制作者は、ノウハウ及び安全性を担保する最小の抽象化レベルを有するブロックを製造者以外向けに提供することで、製造者以外がアプリケーションを開発可能にする。製造者は、一般ユーザに、さらに高い抽象化レベルを有するブロックを提供することで、より多くの人がアプリケーションを開発可能にできる。さらに高い抽象化レベルは、例えば、一般ユーザ自身が専門的な知識がなくても理解できる用語で規定されたブロックに対応する。専門的な知識がなくても理解できる用語は、例えば、家庭用電化製品等の機能自体に対応する内容である。具体的には、洗濯機においての「洗い」ブロック中の水量に関するパラメータとして「たっぷり」を選択した場合に、一つの具体化されたレイヤーにおいては、給水ブロックにおける水位パラメータを６０ｍｍから１００ｍｍに上げ、攪拌ブロックにおける回転数パラメータを１２０ｒｐｍから１００ｒｐｍに下げるなどの変更が行われる。上記より、抽象度の高いレベルにおけるブロックの並べ替え及びパラメータ変更は、より抽象度の低いブロックで実現することができる。また、洗濯機、電子レンジ及び炊飯器以外の装置でも、図５～図７と同様に複数のブロックを定義することができる。これらのブロックにより、アクチュエータ及び加熱器の駆動に関する安全性、秘匿性を担保しながら、その組替、パラメータ調整によって自由にアプリケーション開発を行うことができる。

なお、製造者が他の製造者に、ノウハウ及び安全性を担保する最小の抽象化レベルを有するブロックを提供することで、他の製造者は、提供されたブロックを実現するために、さらに高い具体化レベルを有するブロックを独自で規定し実装を行うことができる。これにより、各製造者がそれぞれのノウハウ及び安全性を担保しながら、アプリのみを開発するサードパーティに対して、各製造者のアクチュエータ及び加熱器の駆動に関するアプリ開発を自由に行うことができる。

この時、他の製造者は、製造者が提供するノウハウ及び安全性を担保する最小の抽象化レベルを有するブロックに合わせた、さらに高い具体化レベルを有するブロックを開発せず、エラーを返し、製造者が提供するブロックが使用できない、または制限されたパラメータ範囲で動作することをアプリ開発者ならびにユーザに提示してもよい。具体的には、洗濯機においての「攪拌」ブロック中のモータ回転に関するパラメータとして、「高速」を選択した場合に、製造者の洗濯機では、「高速」を実現するための１５０ｒｐｍというパラメータが実現可能であるのに対し、他の製造業者の洗濯機ではモータの特性上、１２０ｒｐｍまでしか回転できない場合に、エラーまたは限界値の１２０ｒｐｍで実現する旨をアプリ開発者又はユーザに提示する。

［１．３ 処理］
次に、以上のように構成されたシステム１の処理について図８を参照しながら説明する。図８は、実施の形態１におけるシステム１のシーケンス図である。

［１．３．１ 準備フェーズＦ１００］
まず、準備フェーズＦ１００について説明する。

（ステップＳ１１０）
シーケンスマネージャ１００は、デバイスマネージャ２００にシーケンスマネージャ情報を送信する。このシーケンスマネージャ情報の送信は、例えばシステム管理者の命令により行われる。デバイスマネージャ２００は、受信したシーケンスマネージャ情報を例えばシーケンスマネージャデータベースに登録する。なお、シーケンスマネージャ情報がシーケンスマネージャデータベースに予め登録されている場合は、このステップはスキップされてもよい。

シーケンスマネージャ情報は、例えばシーケンスマネージャ１００の識別子及び／又はアドレス（例えばＵＲＬ（Uniform Resource Locator）、ＩＰ（Internet Protocol）アドレス等）を含む。さらに、シーケンスマネージャ情報は、任意の情報を含んでもよい。

（ステップＳ１１２）
デバイス３００は、デバイスマネージャ２００にデバイス情報１１０１を送信する。このデバイス情報１１０１の送信は、例えばデバイス３００がコンピュータネットワークに接続されたときに行われる。デバイスマネージャ２００は、受信したデバイス情報１１０１をデバイスデータベース１１００に登録する。なお、デバイス情報１１０１がデバイスデータベース１１００に予め登録されている場合は、このステップはスキップされてもよい。

なお、デバイス情報１１０１は、ＵＩ４００に送信されてから、ＵＩ４００を介してデバイスマネージャ２００に登録されてもよい。

デバイス情報１１０１は、デバイス３００の識別子及び／又はアドレスを含む。さらに、デバイス情報１１０１は、任意の情報を含んでもよい。図９は、実施の形態１におけるデバイスデータベースの一例を示す。図９のデバイスデータベース１１００には、デバイス情報１１０１を含む複数のデバイス情報が登録されている。各デバイス情報は、デバイスＩＤと、アドレスと、種別と、製造者名と、型番と、アクチュエータ／加熱器と、劣化レベルと、を含む。アクチュエータ／加熱器は、デバイス３００を構成するアクチュエータ２２及び／又は加熱器２３の識別情報である。劣化レベルは、デバイス３００を構成するアクチュエータ２２及び／又は加熱器２３が劣化しているか否かを示す劣化情報の一例である。ここでは、劣化レベルは、値が増加すればより劣化していることを示す。デバイス情報１１０１に、実行可能なブロックの情報が含まれていてもよい。実行可能なブロックに関する情報とは、データベースに含まれるブロックが実行可能又は実行不可能が対応付けられた情報でもよいし、実行可能なブロックのみの情報でもよい。また、ブロックが実行可能か否かは、デバイス情報１１０１に含まれるアクチュエータ／加熱器などの情報に基づいて予め準備され得る。

なお、デバイス情報１１０１は、施設２ａ～２ｄを特定可能な情報を含んでもよい。

（ステップＳ１１４）
ＵＩ４００は、デバイスマネージャ２００にＵＩ情報を送信する。このＵＩ情報の送信は、例えばユーザの指示により行われる。デバイスマネージャ２００は、受信したＵＩ情報を例えばＵＩデータベースに登録する。なお、ＵＩ情報がＵＩデータベースに予め登録されている場合は、このステップはスキップされてもよい。

ＵＩ情報は、例えばＵＩ４００の識別子及び／又はアドレスを含む。さらに、ＵＩ情報は、任意の情報を含んでもよい。

なお、ＵＩ情報は、施設２ａ～２ｄを特定可能な情報を含んでもよい。

以上の処理により、シーケンスマネージャ１００、デバイスマネージャ２００、デバイス３００及びＵＩ４００は、互いに紐づけられ、互いに接続を確立することができる。このより、準備フェーズＦ１００が終了する。

［１．３．２ アプリ実行前フェーズＦ２００］
次に、アプリ実行前フェーズＦ２００について説明する。なお、アプリ実行前フェーズＦ２００の前には、ＵＩ４００を介したユーザからの指示に従って、アプリケーション配信プラットフォームからシーケンスマネージャ１００にアプリケーションがダウンロードされている。このようにシーケンスマネージャ１００にアプリケーションがダウンロードされた状態で以下の処理が行われる。

（ステップＳ２１０）
ＵＩ４００は、ユーザからアプリ実行要求を受け付け、アプリケーションの識別情報を含むアプリ実行要求をシーケンスマネージャ１００に送信する。例えば、ユーザは、ＵＩ４００を介して、シーケンスマネージャ１００にダウンロードされている複数のアプリケーションの中からアプリケーションを選択し、選択したアプリケーションの実行を指示する。

なお、ＵＩ４００からシーケンスマネージャ１００に送信されるアプリ実行要求は、施設２ａ～２ｄを特定可能な情報とセットで送信される。

なお、アプリ実行要求は、ユーザから明示的に受け付けられなくてもよい。例えば、ユーザの行動又は状態を検出し、検出結果に基づいて自動的にアプリ実行要求がシーケンスマネージャ１００に送信されてもよい。

（ステップＳ２１２）
シーケンスマネージャ１００は、アプリ実行要求によって識別されたアプリケーションの実行内容宣言をデバイスマネージャ２００に送信する。実行内容宣言は、実行するアプリケーションを規定する複数のブロックの情報及び施設２ａ～２ｄを特定可能な情報を含む。

図１０は、実施の形態１における実行内容宣言の一例を示す図である。図１０には、図５に示す洗濯機のための複数のブロックを組み合わせて規定されたアプリケーションのための実行内容宣言１２００が表されている。実行内容宣言１２００は、複数のブロック１２０１、及び、各ブロック１２０１の実行に必要なデバイスに関する情報１２０２、及び、各ブロック１２０１が実行される順番の情報１２０３を含む。

なお、実行内容宣言１２００は、デバイスに関する情報１２０２を含まなくてもよい。その場合、複数のブロック１２０１の情報から、受け取った施設情報が示す施設で該当ブロックを実行可能なデバイスを、デバイスマネージャ２００が検索してデバイス割付けを行う必要がある。

なお、図１０では、デバイスに関する情報１２０２は、デバイス３００の型番を示しているが、これに限定されない。デバイスに関する情報１２０２は、ブロックに割付可能なデバイス３００の条件を示すことができれば、どのような情報であってもよい。例えば、デバイスに関する情報１２０２は、複数の型番を含んでもよいし、デバイスの種別、使用目的、配置場所、又は、これらの任意の組み合わせのみを含んでもよい。

（ステップＳ２１４）
デバイスマネージャ２００は、実行内容宣言に含まれる各ブロックに対して、施設２ａ～２ｄを特定可能な情報を基にして、デバイスマネージャ２００に紐付けられているデバイス３００を割り付ける。例えば、デバイスマネージャ２００は、図１０に示す複数のブロック１２０１の各々に、図９のデバイスデータベース１１００に、受け取った施設情報が示す施設に接続済として登録されている、型番ＷＭ－０００１を有するデバイスＤＥＶ００１を割り付ける。なお、デバイス３００の稼働状態又はクラウドへの接続状態が管理されている場合には、稼働中のデバイス３００の割り付けが禁止されてもよい。

なお、例えば図１０に示す複数のブロックが、受け取った施設情報が示す施設に接続済として登録されていない場合、すなわち、該当施設において対象デバイスが存在していない場合、デバイスマネージャ２００は実行内容宣言されたアプリケーションの実行が不可であることをシーケンスマネージャ１００に通知する。

（ステップＳ２１５）
デバイスマネージャ２００は、デバイス割り付けの結果をデバイス３００に通知する。これにより、アプリケーションに含まれる複数のブロックが、それぞれ割り付けられたデバイス３００に送信される。

（ステップＳ２１６）
デバイス３００は、ブロックの実行前にブロックを確認する。つまり、デバイス３００は、ブロックを実行する前に、ブロックが実行されたときにデバイス３００で問題が生じないかをチェックする。例えばデバイス３００は、安全及び／又は効率上の問題をチェックする。

そして、デバイス３００は、確認結果に基づいて、ブロックを変更する。これにより、問題が生じないようにブロックが修正される。

このような実行前確認処理について、図１１を参照しながら、さらに詳細に説明する。図１１は、実施の形態１における実行前確認処理のフローチャートを示す。

（ステップＳ２１６５）
デバイス３００は、アプリケーションに対応するルールを取得する。ここでは、ルールは、所定の２以上のブロックの１つが実行される場合に当該所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止する。例えば、デバイス３００は、ルールデータベースを参照して、所定の２以上のブロックの組み合わせを取得する。ルールデータベースは、例えばデバイス３００に含まれてもよいし、シーケンスマネージャ１００又はデバイスマネージャ２００に含まれてもよい。

ルールとしては、例えば、第２のブロックが実行される前に第１のブロックが実行されないこと禁止するルールを用いることができる。より具体的には、ルールとして、例えば、アプリケーションの開始から第２のブロックが実行される前までに第１のブロックが実行されないことを禁止するルールを用いることができる。このような第１のブロックには、例えば、第２のブロックを実行可能な環境に設定するためのブロックを用いることができる。具体的には、第１のブロックとして、第２のブロック（例えば脱水ブロック）が実行される前に禁水環境を実現するための排水ブロックを用いることができる。

また、ルールとしては、例えば、第２のブロックが実行された後に第３のブロックが実行されないことを禁止するルールを用いることもできる。より具体的には、ルールとして、例えば、第２のブロックが実行された後からアプリケーションの終了までに第３のブロックが実行されないことを禁止するルールを用いることができる。このような第３のブロックには、例えば、第２のブロックの実行により変化した環境を第２のブロックの実行前の環境に戻すためのブロックを用いることができる。具体的には、第３のブロックとして、第２のブロック（例えば乾燥ブロック）の実行により上昇した温度を当該第２のブロックの実行前の温度に戻すための送風ブロックを用いることができる。

図１２は、実施の形態１におけるルールデータベースの一例を示す。図１２のルールデータベース１３００には、ルール１３０１及び１３０２が登録されている。ルール１３０１及び１３０２の各々は、所定の２以上のブロックの組み合わせの情報を有する。例えば、ルール１３０１は、脱水ブロックが実行される前に排水ブロックが実行されないことが禁止されることを示す。また例えば、ルール１３０２は、乾燥ブロックの後に送風ブロックが実行されないことが禁止されることを示す。

このような所定の２以上のブロックの組み合わせとしては、例えば筐体２１の内部空間、アクチュエータ２２又は加熱器２３を耐久温度に到達させないためのブロックの組み合わせが予め定められる。耐久温度とは、定格温度を意味し、許容される最大温度を示す。したがって、所定の２以上のブロックの組み合わせを用いてアクチュエータ２２又は加熱器２３が駆動されれば、筐体２１の内部空間、アクチュエータ２２又は加熱器２３の温度は、許容されない温度に到達しない。つまり、ルールは、筐体２１の内部空間、アクチュエータ２２又は加熱器２３を耐久温度に到達させないために所定の２以上のブロックが組み合わせて実行されることを担保するためのルールである。

なお、図１２では、ルール１３０１及び１３０２の各々は、２つのブロックの組み合わせを示しているが、これに限定されない。例えば、ルールは、２つのブロックの組み合わせに加えて、当該２つのブロックの少なくとも一方のパラメータの範囲を示してもよい。さらには、ルールは、多種多様なアプリケーションの開発に向けて広い範囲でブロックを利用可能に規定される。

例えば、アクチュエータ２２又は加熱器２３は、筐体２１の内部空間などのデバイス３００の環境に応じて安全に駆動できるルールが変わり、ルールはアクチュエータ２２又は加熱器２３自体の性能のみに依存しない場合がある。したがって、いずれの環境でも安全に駆動するために、安全性を考慮する比重の高いルールになり、多種多様なアプリケーションの開発の余地が低減することになる。そこで、ルールは、アプリケーションと独立して、デバイス３００等の情報と対応付けられてもよい。そのようなルールが用いられることで、安全性及び多種多様なアプリケーションの開発を両立できる。

ルールは、アクチュエータ２２又は加熱器２３が安全に駆動できる範囲に関連する。安全に駆動できる範囲は、ブロックの開始条件又は終了条件を考慮された範囲であってもよい。第１のブロックと、第１のブロックの後に実行される第２のブロックを例に考える。第２のブロックの開始条件に達するまで、第１のブロックを実行することで、アクチュエータ２２又は加熱器２３の安全性に影響がある負荷かかる場合を想定したルールが設定され得る。つまり、ルールは、アクチュエータ２２又は加熱器２３の性能、ブロックの開始条件又は終了条件などに依存する。

ルール１３０１及び１３０２の各々は、さらに、種別と、製造者名と、を有する。これにより、デバイス３００は、ルールデータベース１３００から、ブロックで駆動されるアクチュエータ２２又は加熱器２３に対応するルールを取得することができる。例えば、デバイス３００は、図１２のルールデータベース１３００を参照して、ＷＭ－０００１のためのルール１３０１及び１３０２を取得する。

（ステップＳ２１６６）
デバイス３００は、アプリケーションに含まれる複数のブロックがルールに該当するか否かを判定する。

例えば、ルールが第２のブロックが実行される前に第１のブロックが実行されないことを禁止する場合、アプリケーションが第２のブロックを含み、かつ、当該第２のブロックの前に第１のブロックを含まなければ、デバイス３００は、アプリケーションに含まれる複数のブロックがルールに該当すると判定する。具体的には、アプリケーションが第２のブロックを含み、かつ、第１のブロックを含まない場合に、デバイス３００は、アプリケーションに含まれる複数のブロックがルールに該当すると判定する。また、アプリケーションが第２のブロックを含み、かつ、当該第２のブロックの後のみに第１のブロックを含む場合に、デバイス３００は、アプリケーションに含まれる複数のブロックがルールに該当すると判定する。一方、アプリケーションが第２のブロックを含み、かつ、当該第２のブロックの前に第１のブロックを含む場合に、デバイス３００は、アプリケーションに含まれる複数のブロックがルールに該当しないと判定する。また、アプリケーションが第１のブロック及び第２のブロックをともに含まない場合に、デバイス３００は、アプリケーションに含まれる複数のブロックがルールに該当しないと判定する。また、アプリケーションが第１のブロックを含み、かつ、第２のブロックを含まない場合に、デバイス３００は、アプリケーションに含まれる複数のブロックがルールに該当しないと判定する。

また例えば、ルールが第２のブロックが実行された後に第３のブロックが実行されないことを禁止する場合、アプリケーションが第２のブロックを含み、かつ、当該第２のブロックの後に第３のブロックを含まなければ、デバイス３００は、アプリケーションに含まれる複数のブロックがルールに該当すると判定する。具体的には、アプリケーションが第２のブロックを含み、かつ、第３のブロックを含まない場合に、デバイス３００は、アプリケーションに含まれる複数のブロックがルールに該当すると判定する。また、アプリケーションが第２のブロックを含み、かつ、当該第２のブロックの前のみに第３のブロック含む場合に、デバイス３００は、アプリケーションに含まれる複数のブロックがルールに該当すると判定する。一方、アプリケーションが第２のブロックを含み、かつ、当該第２ブロックの後に第３のブロックを含む場合に、デバイス３００は、アプリケーションに含まれる複数のブロックがルールに該当しないと判定する。また、アプリケーションが第２のブロック及び第３のブロックをともに含まない場合に、デバイス３００は、アプリケーションに含まれる複数のブロックがルールに該当しないと判定する。また、アプリケーションが第３のブロックを含み、かつ、第２のブロックを含まない場合に、デバイス３００は、アプリケーションに含まれる複数のブロックがルールに該当しないと判定する。

ここで、複数のブロックがルールに該当しないと判定された場合（Ｓ２１６６のＮｏ）、デバイス３００は、以降のステップＳ２１６７をスキップして実行前確認処理を終了する。一方、複数のブロックがルールに該当すると判定された場合（Ｓ２１６６のＹｅｓ）、デバイス３００は、次のステップＳ２１６７に進む。

（ステップＳ２１６７）
デバイス３００は、アプリケーションを変更して実行前確認処理を終了する。アプリケーションの変更とは、（ｉ）複数のブロックに新たなブロックを追加すること、（ｉｉ）複数のブロックの順番を変更すること、（ｉｉｉ）複数のブロックのいずれかを削除すること、又は、（ｉｖ）それらの任意の組み合わせを意味する。これらのアプリケーションの変更方法は、ルールに定義されてもよい。

このようなアプリケーションの変更の具体例について図１３及び図１４を参照しながら説明する。

図１３は、実施の形態１におけるアプリケーションの変更の一例を示す。図１３では脱水ブロック（第２のブロック）の前に排水ブロック（第１のブロック）が追加されている。これにより、脱水ブロックが実行される前に洗濯機内から水を排出することができ、脱水時におけるアクチュエータ２２の安全な駆動を実現することができる。

図１４は、実施の形態１におけるアプリケーションの変更の一例を示す。図１４では、乾燥ブロック（第２のブロック）の後に送風ブロック（第３のブロック）が追加されている。これにより、乾燥によって洗濯機の温度が上昇した後に送風によって洗濯機の温度を低下させることができ、ユーザが洗濯機でやけどすることを抑制することができ、洗濯機の安全性を向上させることができる。

なお、ここでは、洗濯機のためのアプリケーションの変更について説明したが、他の装置についても同様にアプリケーションを変更することができる。

例えば、炊飯器のためのアプリケーションに、スチーム機能を活用する蒸らしブロック（第２のブロック）が含まれ、かつ、当該蒸らしブロックの前にスチームあたためブロック（第１のブロック）が含まれていない場合、蒸らしブロックが実行される１０分前に該当するブロックの前にスチームあたためブロックが追加されてもよい。これにより、蒸らしブロックの実行前にスチームヒータを温めることができ、蒸らしブロックの実行時にスチーム照射をスムーズに行うことが可能となる。

また例えば、電子レンジのためのアプリケーションに、蒸すブロック（第２のブロック）が含まれ、かつ、当該蒸すブロックの前にスチームあたためブロック（第１のブロック）が含まれていない場合、蒸すブロックが実行される１０分前に該当するブロックの前に、スチームあたためブロックが追加されてもよい。これにより、蒸すブロックの実行前にスチームヒータを温めることができ、蒸すブロックの実行時にスチーム照射をスムーズに行うことが可能となる。また、電子レンジのためのアプリケーションに、オーブンブロック（第２のブロック）が含まれ、かつ、当該オーブンブロックの後に送風ブロック（第３のブロック）が含まれていない場合、オーブンブロックの後に送風ブロックが追加されてもよい。これにより、オーブンブロックの実行によって非常に熱くなった庫内を送風ブロックの実行によって冷ますことができ、次のブロック実行を早めることができる。

（ステップＳ２１７）
デバイス３００は、実行前確認の結果をデバイスマネージャ２００に送信する。ブロックが変更されている場合には、変更されたブロックがデバイスマネージャ２００に送信されてもよい。

（ステップＳ２１８）
デバイスマネージャ２００は、デバイス割り付けの結果をシーケンスマネージャ１００に回答する。また、実行前確認においてブロックが変更されている場合には、変更されたブロックを含むアプリケーションがシーケンスマネージャ１００に送信されてもよい。

（ステップＳ２２０）
シーケンスマネージャ１００は、デバイスマネージャ２００からの割付結果通知を受けて、ＵＩ４００を介してユーザに実行準備完了を通知する。

（ステップＳ２２２）
ＵＩ４００は、アプリケーションが実行されるデバイスの一覧を表示するとともに、ユーザからアプリケーション実行の確認の入力を受け付けるためのグラフィカルユーザインタフェース（ＧＵＩ）を表示する。なお、ＵＩ４００は、ユーザからデバイスの割り付けの変更を受け付けてもよい。また、ＵＩ４００は、デバイスの一覧を表示しなくてもよい。

（ステップＳ２２４）
ＵＩ４００は、ユーザから実行確認の入力を受けて、デバイスマネージャ２００にアプリ開始指示を送信する。デバイスマネージャ２００は、アプリ開始指示をシーケンスマネージャ１００に転送する。

なお、ステップＳ２２０、Ｓ２２２、及びＳ２２４は、アプリケーションが実行される前にユーザに改めて情報を提供しているが、ユーザの作業が増える可能性があるため、省略されてもよい。

以上により、アプリ実行前フェーズＦ２００が終了する。

［１．３．３ アプリ実行フェーズＦ３００］
次に、アプリ実行フェーズＦ３００について説明する。

（ステップＳ３１０）
シーケンスマネージャ１００は、アプリ開始指示を受けて、アプリケーションに含まれる複数のブロックの中から最初のブロック（第１ブロック）を選択する。そして、シーケンスマネージャ１００は、選択した第１ブロックの実行指示をデバイスマネージャ２００に送信する。

なお、複数のブロックが連続して動作される場合、シーケンスマネージャ１００は、複数のブロックの実行指示をまとめてデバイスマネージャ２００に送信してもよい。

デバイスマネージャ２００は、シーケンスマネージャ１００から受信した第１ブロックの実行指示に基づいて、第１ブロックに割り付けられたデバイス３００に第１ブロックの実行指示を送信する。

（ステップＳ３１２）
デバイスマネージャ２００は、第１ブロックの実行指示を受けて、各デバイスのスケジュール（使用予定時間）を更新する。

（ステップＳ３１４）
デバイス３００は、第１ブロックの実行指示を受けて、第１ブロックを実行する。

（ステップＳ３１６）
デバイス３００は、第１ブロックの実行が完了したときに、完了通知をデバイスマネージャ２００に送信する。なお、第１ブロックの実行中にエラーが発生した場合には、デバイス３００は、エラー情報をデバイスマネージャ２００に送信してもよい。また、デバイス３００は、第１ブロックの実行中に、イベント情報をデバイスマネージャ２００に送信してもよい。イベント情報としては、例えば、センサの出力値又は機器操作等を用いることができるが、これに限定されない。デバイスマネージャ２００は、デバイス３００から受信した完了通知及び／又は各種情報をシーケンスマネージャ１００に転送する。

（ステップＳ３１８）
シーケンスマネージャ１００は、第１ブロックの完了通知を受けて、アプリケーションの進捗を更新し、次のブロック（第２ブロック）を選択する。また、シーケンスマネージャ１００は、エラー情報を受信した場合に、エラー情報に対応する処理（例えば、１つ前のブロックに戻る、最初のブロックに戻る、待機等）を実行する。エラー情報に対応する処理の情報は、例えば、シーケンスマネージャ１００に予め保持されてもよいし、ＵＩ４００を介してユーザから受け付けられてもよい。また、シーケンスマネージャ１００は、イベント情報を受信した場合に、イベント情報に対応する処理を実行する。例えば、イベント情報に水位センサの出力値が含まれる場合、シーケンスマネージャ１００は、実行中のブロックに含まれる水位を表示するための水位パラメータを更新する。

（ステップＳ３２０）
シーケンスマネージャ１００は、選択した第２ブロックの実行指示をデバイスマネージャ２００に送信する。

なお、第２ブロックの実行指示は、第１ブロックの実行指示（Ｓ３１０）と同一のデバイスに対する指示でもよいし、異なるデバイスへの指示でもよい。

なお、第２ブロックの実行指示は、第１ブロックの実行指示と同様に、複数のブロックの実行指示をまとめてデバイスマネージャ２００に送信してもよい。

以降の処理は第１ブロックのための処理（Ｓ３１２～Ｓ３１８）と同様であるので、図示及び説明を省略する。アプリケーションに含まれるブロックが順に実行され、最後のブロックの実行が完了すれば、アプリ実行フェーズＦ３００が終了する。

なお、ここでは、ブロックの実行は１つずつ順に指示されているが、これに限定されない。例えば、同一のデバイスが割り付けられた複数のブロックの実行は、まとめて指示されてもよい。その場合、あらかじめ各ブロックが機能実行のパラメータ範囲を満たすかの確認を行ったり、変更に対応するブロックを実行前にデバイス側にダウンロードしたりしてもよい。また、例えば、複数のデバイスに対して各々のブロック実行指示を行ってもよい。

［１．４ 効果など］
以上のように、ブロックを含むアプリケーションとルールデータベースとにより、多様多種なアプリケーションを開発可能な環境を提供し、その環境下で自由に開発したアプリケーションに対して、物理的に運動するアクチュエータ２２、又は熱エネルギーを出力する加熱器２３を安全に駆動することを可能にしている。言い換えると、アプリケーションを自由に開発可能な環境を提供するとともに、アプリケーションと独立して安全性を担保するための機能を提供できる。その結果、例えば、自由度の高い多様多種なアプリケーションの開発と、安全性を担保するためのルールデータベースの開発とを並行して作成することが可能になり、多様多種なアプリケーションを早期に開発することを可能にすることができる。

また、アプリケーションの提供後においても、ルールデータベースを変更することで、より安全性を担保したアプリケーションへの変更も可能になる。また、事前に製造者が想定しない状況の改善が必要になった場合においても、多様多種なアプリケーション自体を変更せずとも、アプリケーションとは独立して、ルールデータベースを規定していることで、ルールデータベースを更新することで、全てのアプリケーションへの対応が可能になる。

アプリケーション自体を変更せずに、アプリケーションが実行されたときの状態を検知することでエラー処理のルールデータベースを保持する対処方法も考えられる。しかし、この対処方法は、常にエラーの状態になった後に対処することになり、家電に負荷がかかる状況、又は安全性が担保できない状況になることを許容することを意味する。そこで、アプリケーションとは独立にルールデータベースを保有し、ルールデータを参照してアプリケーションの内容を変更することで、安全性を担保することを可能にしている。

本実施の形態における装置２０は、アクチュエータ２２及び加熱器２３の少なくとも１つと、アクチュエータ２２及び加熱器２３の少なくとも１つを制御する制御部２４と、を備え、制御部２４は、アクチュエータ２２及び加熱器２３の少なくとも１つを駆動する複数のブロックで規定されたアプリケーションを取得し、所定の２以上のブロックの１つが実行される場合に所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止するルールを参照して、アプリケーションに含まれる複数のブロックがルールに該当する場合、アプリケーションを変更し、変更されたアプリケーションに基づいて、アクチュエータ２２及び加熱器２３の少なくとも１つを駆動する。

これによれば、複数のブロックで規定されたアプリケーションに基づいてアクチュエータ２２及び／又は加熱器２３を駆動することができる。したがって、装置２０の制御を抽象化したブロックを用いたアプリケーションの開発が可能となり、多種多彩なアプリケーションを製造者だけではなく、サードパーティも開発することができ、これらのアプリケーションを装置２０で簡単に実行することが可能となる。さらに、アプリケーションが、所定の２以上のブロックの１つが実行される場合に所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止するルールに該当する場合に、アプリケーションに基づいてアクチュエータ２２及び／又は加熱器２３が駆動される前に、アプリケーションを変更することができる。したがって、所定の２以上のブロックの１つが所定の２以上のブロックの残りの少なくとも１つと組み合わせて実行されることを担保することができる。つまり、もしアプリケーション開発者が誤って単独での実行が許容されないブロックを単独で実行するよう指示を行った場合でも、装置２０を安全に制御することができないアプリケーションが実行されることを抑制することができる。したがって、アプリケーション開発者は、アクチュエータ２２及び／又は加熱器２３の安全性の担保よりもユーザに適することを重視したアプリケーションを作成した場合でも、アプリケーションで制御される装置２０の安全性を向上させることができる。

また例えば、本実施の形態における装置２０において、制御部２４は、（ａ）複数のブロックに新たなブロックを追加し、（ｂ）複数のブロックの順番を変更し、又は、（ｃ）複数のブロックのうちいずれかのブロックを削除することで、アプリケーションを変更してもよい。

より具体的には、例えば、本実施の形態における装置２０において、アプリケーションは、複数のブロックのそれぞれが実行される順番の情報を含み、所定の２以上のブロックは、第１のブロック及び第２のブロックを含み、ルールは、第２のブロックが実行される前に、第１のブロックが実行されないことを禁止し、制御部２４は、アプリケーションが第２のブロックを含み、かつ、第２のブロックの前に第１のブロックを含まない場合に、第２のブロックの前に、第１のブロックを追加することで、アプリケーションを変更してもよい。

また例えば、本実施の形態における装置２０において、アプリケーションは、複数のブロックのそれぞれが実行される順番の情報を含み、所定の２以上のブロックは、第１のブロック及び第２のブロックを含み、ルールは、第２のブロックが実行される前に、第１のブロックが実行されないことを禁止し、制御部２４は、アプリケーションが、第１のブロック及び第２のブロックを含み、かつ、第２のブロックの前に第１のブロックを含まない場合に、第１のブロックの順番を第２のブロックの順番よりも前に変更することで、アプリケーションを変更してもよい。

また例えば、本実施の形態における装置２０において、アプリケーションは、複数のブロックのそれぞれが実行される順番の情報を含み、所定の２以上のブロックは、第１のブロック及び第２のブロックを含み、ルールは、第２のブロックが実行される前に、第１のブロックが実行されないことを禁止し、制御部２４は、アプリケーションが第２のブロックを含み、かつ、第２のブロックの前に第１のブロックを含まない場合に、第２のブロックを削除することで、アプリケーションを変更してもよい。

これらによれば、アプリケーションが実行される前に、新たなブロックを追加、ブロックの順番を変更、又は、ブロックを削除することで、第２のブロックの前に第１のブロックが実行されることを担保することができる。したがって、アプリケーションの開発者は、アクチュエータ２２及び加熱器２３が安全に駆動することを考慮する優先度を下げて自由にアプリケーションを開発ができる。さらに、アクチュエータ２２及び加熱器２３を制御する装置２０に組み込まれるソフトウェアの開発者は、アプリケーション一つ一つの安全性を毎回チェックすることなくブロックの実行を許可することができる。

また例えば、本実施の形態における装置２０において、アプリケーションは、複数のブロックのそれぞれが実行される順番の情報を含み、所定の２以上のブロックは、第２のブロック及び第３のブロックを含み、ルールは、第２のブロックが実行された後に、第３のブロックが実行されないことを禁止し、制御部２４は、アプリケーションが第２のブロックを含み、かつ、第２のブロックの後に第３のブロックを含まない場合に、第２のブロックの後に、第３のブロックを追加することで、アプリケーションを変更してもよい。

また例えば、本実施の形態における装置２０において、アプリケーションは、複数のブロックのそれぞれが実行される順番の情報を含み、所定の２以上のブロックは、第２のブロック及び第３のブロックを含み、ルールは、第２のブロックが実行された後に、第３のブロックが実行されないことを禁止し、制御部２４は、アプリケーションが、第２のブロック及び第３のブロックを含み、かつ、第２のブロックの後に第３のブロックを含まない場合に、第３のブロックの順番を第２のブロックの順番よりも後に変更することで、アプリケーションを変更してもよい。

また例えば、本実施の形態における装置２０において、アプリケーションは、複数のブロックのそれぞれが実行される順番の情報を含み、所定の２以上のブロックは、第２のブロック及び第３のブロックを含み、ルールは、第２のブロックが実行された後に、第３のブロックが実行されないことを禁止し、制御部２４は、アプリケーションが第２のブロックを含み、かつ、第２のブロックの後に第３のブロックを含まない場合に、第２のブロックを削除することで、アプリケーションを変更してもよい。

また例えば、本実施の形態における装置２０において、アプリケーションは、複数のブロックの情報とそれぞれが実行される順番の情報を含み、ルールは、複数のブロックの中で少なくとも一つのブロックが実行できない情報を含む場合に、エラー情報として、本アプリケーションが開発できないこと、または、実行できないブロックの情報を開発者に提示してもよい。

これらによれば、アプリケーションが実行される前に、新たなブロックを追加、ブロックの順番を変更、又は、ブロックを削除することで、第２のブロックの後に第３のブロックが実行されることを担保することができる。したがって、アプリケーションの開発者は、アクチュエータ２２及び加熱器２３が安全に駆動することを考慮する優先度を下げて自由にアプリケーションを開発ができる。さらに、アクチュエータ２２及び加熱器２３を制御する装置２０に組み込まれるソフトウェアの開発者は、アプリケーション一つ一つの安全性を毎回チェックすることなくブロックの実行を許可することができる。

また例えば、本実施の形態における装置２０において、ルールは、アクチュエータ２２及び加熱器２３の少なくとも１つを耐久温度に到達させないために所定の２以上のブロックが組み合わせて実行されることを担保するためのルールであってもよい。

これによれば、アプリケーションが実行されたときにアクチュエータ２２及び／又は加熱器２３が耐久温度に到達することを抑制することができ、アプリケーションで制御される装置２０の安全性を向上させることができる。

また例えば、本実施の形態における装置２０は、内部空間を有する筐体２１を備えてもよく、第１のルールは、内部空間を耐久温度に到達させないために所定の２以上のブロックが組み合わせて実行されることを担保するためのルールであってもよい。

これによれば、アプリケーションが実行されたときに筐体２１の内部空間が耐久温度に到達することを抑制することができ、アプリケーションで制御される装置２０の安全性を向上させることができる。

（実施の形態１の変形例）
なお、上記実施の形態１では、システム１の処理について図８を参照しながら説明したが、処理の流れについてはこれに限定されない。特に、詳細に説明している実行前確認（Ｓ２１６）について、実行前確認が行われるタイミング及び主体となるモジュールはこれに限定されない。そこで、システム１のシーケンス図のいくつかの変形例について、図１５Ａ～図１５Ｅを参照しながら具体的に説明する。

図１５Ａは、実施の形態１の変形例１におけるシステム１のシーケンス図である。図１５Ａでは、実行前確認（Ｓ２１６）は、デバイス３００が実行指示を受けて（Ｓ３１０）ブロックを実行する（Ｓ３１４）直前に、デバイス３００によって行われる。

これにより、デバイス３００に組み込まれるソフトウェアは、ブロックの実行直前に実行前確認を行うというシンプルな構成とすることができる。すなわち、ステップＳ２１５及びＳ２１７を省略することができる。その結果、それらの処理を行うための機能及び通信ＡＰＩをデバイス３００に組み込む必要がなくなり、デバイス３００に搭載されるマイコンの使用メモリ等を低減することが可能となる。

なお、実行前確認の結果がデバイスマネージャ２００及び／又はＵＩ４００に通知されてもよい。例えば、実行前確認を行った結果としてパラメータの変更又はブロックの実行停止指示が行われた場合に、デバイスマネージャ２００又はＵＩ４００に確認結果が通知されてもよい。

図１５Ｂは、実施の形態１の変形例２におけるシステム１のシーケンス図である。図１５Ｂでは、実行前確認（Ｓ２１６）は、デバイスマネージャ２００が割付結果通知（Ｓ２１８）を行う際に、そのままデバイスマネージャ２００によって行われる。

これにより、デバイス３００に組み込まれるソフトウェアは、実行前確認（Ｓ２１６）の機能を含まなくてもよい。したがって、デバイス３００が有するメモリの使用を抑えることができ、デバイス３００のコストダウンにつながる。

また、上記実施の形態１では、デバイス３００によるブロック実行（Ｓ３１４）について、クラウドサーバ１０に実装されたシーケンスマネージャ１００からの指示によって行われる処理の流れを説明したが、ブロック実行（Ｓ３１４）が行われる形態についても、これに限定されない。

例えば、シーケンスマネージャ１００からの通知内容を、デバイス３００内のメモリに保存し、装置２０が有するＵＩ又は端末３０が有するＵＩ４００を通じたユーザからの直接の指示により、ブロックが実行されてもよい。すなわち、アプリケーションをデバイス内にダウンロードしておいて、ユーザが任意のタイミングでアプリケーションを実行する形態としてもよい。

図１５Ｃは、実施の形態１の変形例３におけるシステム１のシーケンス図である。図１５Ｃでは、アプリ実行フェーズＦ３００において、シーケンスマネージャ１００からデバイス３００に、デバイス３００で実行される１以上のブロックが通知される（Ｓ３１０Ｃ）。そして、デバイス３００は、通知された１以上のブロックをメモリに保存する（Ｓ３１１Ｃ）。

その後、デバイス３００は、ユーザから、保存された１以上のブロックの実行の指示を受け付け（Ｓ３１２Ｃ）、１以上のブロックを第１ブロックから順に実行する（Ｓ３１４）。

以上のように、ブロックをデバイス３００に保存することで、デバイスマネージャ２００とデバイス３００との通信を介さずにデバイス３００の制御が行えるため、クラウドサーバ１０と装置２０間の通信が不安定になることによってデバイス３００の動作が停止したり遅延が生じたりするリスクを低減することができる。そのため、本変形例は、クラウドサーバ１０との通信の信頼性が低い環境において、及び／又は、アプリケーション実行中のデバイスの動作停止や遅延が許容されないデバイス３００において、より効果的である。

なお、変形例３においても、実施の形態１と同様に、実行前確認（Ｓ２１６）は重要な意味を有するが、実行前確認（Ｓ２１６）が行われるタイミングや主体となるモジュールは図１５Ｃに限定されない。すなわち、変形例３は、変形例１又は２と組み合わされてもよい。

図１５Ｄは、実施の形態１の変形例４におけるシステム１のシーケンス図である。変形例４は、変形例１と変形例３との組み合わせに相当する。変形例４では、図１５Ｄに示すように、実行前確認（Ｓ２１６）は、デバイス３００が実行指示を受けて（Ｓ３１２Ｃ）ブロックを実行する（Ｓ３１４）直前にデバイス３００によって行われる。

ブロックをデバイス３００にダウンロードしておいて、ユーザが任意のタイミングでブロックを実行する場合、ブロックをダウンロードするタイミングと実行するタイミングが大きくずれる可能性が高まる。すなわち、ブロックをデバイス３００にダウンロードしてから数日後、数か月後、又は数年後等にブロックが実行される場合が考えられる。その場合、ブロックがダウンロードされてからブロックが実行されるまでの間にデバイス３００の劣化レベル等が変わる恐れもある。そのため、ブロックの実行が劣化レベルの影響を受けるデバイス３００では、ブロックが実行される直前にデバイス３００によって実行前確認が行われることで、劣化レベルに応じた実行前確認が可能となる。

図１５Ｅは、実施の形態１の変形例５におけるシステム１のシーケンス図である。変形例５は、変形例２と変形例３との組み合わせに相当する。変形例５では、図１５Ｅに示すように、実行前確認（Ｓ２１６）は、デバイスマネージャ２００が割付結果通知（Ｓ２１８）を行う際に、そのままデバイスマネージャ２００によって行われる。

（実施の形態２）
次に、実施の形態２について説明する。本実施の形態では、アプリケーションが認証済みである場合に実行前確認がスキップされる点が上記実施の形態１と主として異なる。以下に、上記実施の形態１と異なる点を中心に本実施の形態について説明する。

なお、本実施の形態におけるシステム１のハードウェア構成及び機能構成は、上記実施の形態１と同様であるので、図示及び説明を省略する。

［２．１ 処理］
本実施の形態では、上記実施の形態１における実行前確認のステップＳ２１６がステップＳ２１６Ａに代わる点を除いて、上記実施の形態１の処理と同様である。したがって、実行前確認処理のステップＳ２１６Ａについて図１６を参照しながら説明する。

図１６は、実施の形態２における実行前確認処理のフローチャートを示す。

（ステップＳ２１６１Ａ）
デバイス３００は、アプリ認証情報を取得する。アプリ認証情報は、アプリケーションが認証済みである場合に認証済みであることを示す情報を含む。

アプリケーションの認証は、例えばアプリケーションの品質を保証するための仕組みであり、アプリケーションの安全性及び／又は同一性（改ざんされていないこと）などの確認を可能とする。認証情報の付与されているアプリケーションの一例を説明する。アプリケーションのコードの変更履歴がパラメータ範囲の変更が行われなかったことを示す場合、アプリケーションに認証済みであることを示す情報が対応付けられている。

（ステップＳ２１６２Ａ）
デバイス３００は、取得されたアプリ情報に基づいて、アプリケーションが認証済みであるか否かを判定する。ここで、アプリケーションが認証済みであると判定された場合（Ｓ２１６２ＡのＹｅｓ）、デバイス３００は、以降のステップＳ２１６５～ステップＳ２１６７をスキップして実行前確認処理を終了する。一方、アプリケーションが認証済みではないと判定された場合（Ｓ２１６２ＡのＮｏ）、デバイス３００は、次のステップＳ２１６５に進む。

［２．２ 効果など］
以上のように、本実施の形態における装置２０は、アクチュエータ２２及び加熱器２３の少なくとも１つと、アクチュエータ２２及び加熱器２３の少なくとも１つを制御する制御部２４と、を備え、制御部２４は、アクチュエータ２２及び加熱器２３の少なくとも１つを駆動する複数のブロックで規定され、かつ認証済みか否かを示す情報を含むアプリケーションを取得し、アプリケーションが認証済みであることを示す情報を含まない場合、所定の２以上のブロックが組み合わせて実行されることを示すルールを参照して、アプリケーションに含まれる複数のブロックがルールに該当しない場合、アプリケーションを変更し、変更されたアプリケーションに基づいて、アクチュエータ２２及び加熱器２３の少なくとも１つを駆動する。

これによれば、実施の形態１と同様の効果を実現することができる。さらに、アプリケーションが認証済みでない場合に、アプリケーションの変更を伴う処理を行うことができ、アプリケーションが認証済みである場合に処理負荷の軽減を図ることができる。したがって、全てのアプリケーションに対するブロックの組み合わせに対する判定処理を行う必要は無く、認証を行うことによる管理によって、処理負荷の軽減とともに、ブロックの組み合わせに関する設計の基準ができ、アプリケーション開発者にとっては、より容易かつ安全な設計が可能となる。

また例えば、本実施の形態における装置２０において、アプリケーションが認証済みであることを示す情報を有する場合、第１のルールを参照せずに、アプリケーションを変更しなくてもよい。

これによれば、アプリケーションが認証済みである場合に、ブロックを変更するための処理をスキップすることができ、処理負荷を軽減することができる。

（実施の形態３）
次に、実施の形態３について説明する。本実施の形態では、アプリケーションの制作者と装置の製作者とが同一である場合に実行前確認がスキップされる点が上記実施の形態１と主として異なる。以下に、上記実施の形態１と異なる点を中心に本実施の形態について説明する。

なお、本実施の形態におけるシステム１のハードウェア構成及び機能構成は、上記実施の形態１と同様であるので、図示及び説明を省略する。

［３．１ 処理］
本実施の形態では、上記実施の形態１における実行前確認のステップＳ２１６がステップＳ２１６Ｂに代わる点を除いて、上記実施の形態１の処理と同様である。したがって、実行前確認処理のステップＳ２１６Ｂについて図１７を参照しながら説明する。

図１７は、実施の形態３における実行前確認処理のフローチャートを示す。

（ステップＳ２１６１Ｂ）
デバイス３００は、アプリ制作者情報を取得する。アプリ制作者情報は、アプリケーションの制作者を示す。制作者は、アプリケーションを制作した会社、個人又は団体等を意味し、開発者又は著者と呼ばれる場合もある。

（ステップＳ２１６３Ｂ）
デバイス３００は、デバイス製造者情報を取得する。デバイス製造者情報は、デバイスの製作者を示す。製作者は、デバイス３００（つまり装置２０）を製作した会社、個人又は団体等を意味し、製造者と呼ばれる場合もある。

（ステップＳ２１６４Ｂ）
デバイス３００は、アプリケーションの制作者とデバイス３００の製作者とが異なるか否かを判定する。アプリケーションの制作者が個人であり、デバイス３００の製作者が会社である場合、デバイス３００は、アプリケーションの制作者が属する会社とデバイス３００の製作者とが一致すれば、アプリケーションの制作者とデバイス３００の製作者とが同じであると判定してもよい。また、デバイス３００は、アプリケーションの制作者がデバイス３００の製作者の開発委託先であれば、アプリケーションの制作者とデバイス３００の製作者とが同じであると判定してもよい。

ここで、アプリケーションの制作者とデバイス３００の製作者とが同じである場合（Ｓ２１６４ＢのＮｏ）、デバイス３００は、以降のステップＳ２１６５～ステップＳ２１６７をスキップして実行前確認処理を終了する。一方、アプリケーションの制作者とデバイス３００の製作者とが異なる場合（Ｓ２１６４ＢのＹｅｓ）、デバイス３００は、次のステップＳ２１６５に進む。

［３．２ 効果など］
以上のように、本実施の形態における装置２０は、アクチュエータ２２及び加熱器２３の少なくとも１つと、アクチュエータ２２及び加熱器２３の少なくとも１つを制御する制御部２４と、を備え、制御部２４は、アクチュエータ２２及び加熱器２３の少なくとも１つを駆動する複数のブロックで規定され、かつ制作者を示す情報を含むアプリケーションを取得し、装置２０の製作者を示す情報を取得し、アプリケーションの制作者と装置２０の製作者とが異なる場合、所定の２以上のブロックが組み合わせて実行されることを示すルールを参照して、アプリケーションに含まれる複数のブロックがルールに該当しない場合、アプリケーションを変更し、変更されたアプリケーションに基づいて、アクチュエータ２２及び加熱器２３の少なくとも１つを駆動する。

これによれば、実施の形態１と同様の効果を実現することができる。さらに、アプリケーションの制作者と装置２０の製造者とが異なる場合に、アプリケーションの変更を伴う処理を行うことができ、アプリケーションの制作者と装置２０の製造者とが同じ場合には、処理負荷の軽減を図ることができる。

（実施の形態４）
次に、実施の形態４について説明する。本実施の形態では、装置の劣化レベルに対応するルールを用いて実行前確認が行われる点が上記実施の形態１と主として異なる。以下に、上記実施の形態１と異なる点を中心に本実施の形態について説明する。

なお、本実施の形態におけるシステム１のハードウェア構成及び機能構成は、上記実施の形態１と同様であるので、図示及び説明を省略する。

［４．１ 処理］
本実施の形態では、上記実施の形態１における実行前確認のステップＳ２１６がステップＳ２１６Ｃに代わる点を除いて、上記実施の形態１の処理と同様である。したがって、実行前確認処理のステップＳ２１６Ｃについて図１８を参照しながら説明する。

図１８は、実施の形態４における実行前確認処理のフローチャートを示す。

（ステップＳ２１６３Ｃ）
デバイス３００は、デバイス劣化情報を取得する。デバイス劣化情報は、装置２０に含まれるアクチュエータ２２及び／又は加熱器２３の劣化レベルを示す。劣化レベルの検出方法は、特に限定されず、例えばセンサによって検出されればよい。

（ステップＳ２１６５Ｃ）
デバイス３００は、劣化レベルに対応するルールを取得する。例えば、デバイス３００は、ルールデータベースを参照して、ブロックが駆動するアクチュエータ２２又は加熱器２３の劣化レベルに対応するルールを取得する。

なお、劣化レベルを決定する項目は、例えば、デバイス３００に含まれるアクチュエータ２２及び／又は加熱器２３の使用回数、使用時間、又は稼働開始から現在まで使用日数である。これらの項目は、ユーザの使用に対して概ね比例関係で増えると想定される。よって、項目に対応する値が大きくなるごとに、劣化レベルが大きくなるようにルールが決定される。

また、劣化レベルを決定する項目は、例えば、加熱器２３の温度の加算値、又はアクチュエータ２２及び／又は加熱器２３の入力及び出力の再現度合である。加熱器２３の温度の加算値とは、加熱器２３が駆動されたときの温度を加算した値である。例えば、ブロック実行時の加熱器２３の平均温度、中間温度、又は最大温度が用いられる。加熱器２３の温度は、加熱器２３の限界温度に対する実行温度の割合、加熱器２３の限界温度に対する実行温度の差分であってもよい。

アクチュエータ２２及び／又は加熱器２３の入力及び出力の再現度合とは、アクチュエータ２２及び／又は加熱器２３を駆動するための入力値とアクチュエータ２２及び／又は加熱器２３の出力との関係を参照して求められる。所定の入力に対する実際の出力値と、関係に規定された出力値との割合が用いられる。

［４．２ 効果など］
以上のように、本実施の形態における装置２０は、アクチュエータ２２及び加熱器２３の少なくとも１つと、アクチュエータ２２及び加熱器２３の少なくとも１つを制御する制御部２４と、を備え、制御部２４は、アクチュエータ２２及び加熱器２３の少なくとも１つを駆動する複数のブロックで規定されたアプリケーションを取得し、アクチュエータ２２及び加熱器２３の少なくとも１つが劣化しているか否かを示す劣化情報を取得し、劣化情報に対応するルールであって所定の２以上のブロックが組み合わせて実行されることを示すルールを参照して、アプリケーションに含まれる複数のブロックがルールに該当しない場合、アプリケーションを変更し、変更されたアプリケーションに基づいて、アクチュエータ２２及び加熱器２３の少なくとも１つを駆動する。

これによれば、実施の形態１と同様の効果を実現することができる。さらに、装置２０の劣化情報に対応するルールを用いることができ、ブロックを用いることで、経年劣化していくデバイスのパフォーマンスを考慮しながら、アプリケーション側からのアクチュエータ２２及び／又は加熱器２３への駆動指示を実行し、アプリケーションで制御される装置２０の安全性をより向上させることができる。

（実施の形態５）
上記実施の形態１～４では、既に配信されているアプリケーションに含まれるブロックが、そのアプリケーションが実行される前に変更される。本実施の形態では、そのアプリケーションが変更されるタイミングが、アプリケーションが配信される前、つまり、そのアプリケーションが開発または制作される段階であって、その点で本実施の形態は上記実施の形態１～４とは異なる。以下、本実施の形態について、上記実施の形態１～４と異なる点を中心に、詳細に説明する。なお、本実施の形態は、アプリケーションの変更のタイミング以外については、上記実施の形態１～４と同様であってもよい。また、本実施の形態における各構成要素のうち、実施の形態１～４と同一の構成要素については、実施の形態１～４と同一の符号を付し、詳細な説明を省略する。

［５．１ 構成］
図１９は、アプリケーションの開発に用いられる情報処理システムの構成例を示す図である。

情報処理システム２０００は、ブロックデータベース４１と、ルールデータベース４２と、開発ツール５０と、複数の装置２０および複数の端末３０と、アプリ提供サーバ６０と、シーケンスマネージャ１００とを備える。例えば、情報処理システム２０００に備えられるこれらの構成要素は、インターネットなどの通信ネットワークを介して接続される。

ブロックデータベース４１は、ブロックＤＢとも呼ばれ、複数の機能ブロックを含むブロック一覧を格納している記録媒体である。なお、これらの機能ブロックは、実施の形態１～４と同様、ブロックとも呼ばれる。ルールデータベース４２は、ルールＤＢとも呼ばれ、複数のルールを格納している記録媒体である。なお、ルールデータベース４２は、例えば図１２に示すルールデータベース１３００と同様であってもよい。また、これらの記録媒体は、ハードディスク、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、または半導体メモリなどである。なお、このような記録媒体は、揮発性であっても不揮発性であってもよい。

開発ツール５０は、例えば、プロセッサ５１と、メモリ５２と、ディスプレイ５３と、入力部５４とを備えるコンピュータシステムである。プロセッサ５１は、例えばメモリ５２に格納されたインストラクション又はソフトウェアプログラムを実行することによって後述の各処理を実行し、ディスプレイ５３に文字または画像などを表示する。ディスプレイ５３は、例えば液晶ディスプレイ、プラズマディスプレイ、有機ＥＬ（Electro-Luminescence）ディスプレイなどであるが、これらに限定されない。入力部５４は、例えばキーボード、タッチセンサ、タッチパッドまたはマウスなどとして構成されている。このような開発ツール５０は、例えばアプリケーションの開発者によって利用され、複数の機能ブロックを含むシーケンスまたはアプリケーションを生成する。なお、本実施の形態では、この開発ツール５０は、情報処理装置の一例である。

アプリ提供サーバ６０は、開発ツール５０によって生成されたアプリケーションを、その開発ツール５０から通信ネットワークを介して取得して保持する。そして、アプリ提供サーバ６０は、端末３０に備えられているＵＩ４００からの指示に応じて、保持しているアプリケーションをシーケンスマネージャ１００にダウンロードする。

図２０は、ブロックデータベース４１およびルールデータベース４２のそれぞれに格納されている情報の一例を示す図である。

ブロックデータベース４１は、図２０の（ａ）に示すように、複数種の装置２０のそれぞれについて、その種別の装置２０を駆動するための機能ブロックの一覧を、上述のブロック一覧として格納している。例えば、ブロック一覧４１ａ～４１ｅが格納されている。ブロック一覧４１ａは、オーブンレンジを駆動するための機能ブロックＦＢ１１～ＦＢ１４などを含む。ブロック一覧４１ｂは、マルチクッカーを駆動するための機能ブロックＦＢ２１～ＦＢ２４などを含む。これらの機能ブロックは、上記実施の形態１～４のブロックと同一または類似であってもよい。

ルールデータベース４２は、図２０の（ｂ）に示すように、複数種の装置２０のそれぞれについて、その種別の装置２０に適用される少なくとも１つのルールからなるルール群を格納している。例えば、ルール群４２ａ～４２ｅが格納されている。ルール群４２ａは、オーブンレンジに適用されるルールＲ１００およびＲ１１～Ｒ１３などを含む。ルール群４２ｂは、マルチクッカーに適用されるルールＲ２００およびＲ２１～Ｒ２３などを含む。また、ルール群４２ｄは、洗濯機に適用されるルールＲ４００およびＲ４１～Ｒ４３などを含む。これらのルールは、上記実施の形態１～４のルールと同一または類似であってもよい。

ここで、オーブンレンジのルールＲ１１～Ｒ１３のそれぞれは、例えば、所定のメーカによって製造された所定の型式のオーブンレンジに適用される専用ルールである。同様に、マルチクッカーのルールＲ２１～Ｒ２３のそれぞれは、例えば、所定のメーカによって製造された所定の型式のマルチクッカーに適用される専用ルールである。同様に、洗濯機のルールＲ４１～Ｒ４３のそれぞれは、所定のメーカによって製造された所定の型式の洗濯機に適用される専用ルールである。具体的には、その専用ルールＲ４１～Ｒ４３のそれぞれは、例えば図１２に示すルール１３０１または１３０２であってもよい。

一方、オーブンレンジのルールＲ１００は、例えば、複数種のオーブンレンジのそれぞれに適用可能な、オーブンレンジの汎用ルールである。同様に、マルチクッカーのルールＲ２００は、例えば、複数種のマルチクッカーのそれぞれに適用可能な、マルチクッカーの汎用ルールである。

図２１は、ルールデータベース４２に含まれる汎用ルールの一例を示す図である。

ルールデータベース４２に格納されている洗濯機のルール群４２ｄには、例えば図２１の（ａ）に示す汎用ルールＲ４００が含まれている。この汎用ルールＲ４００は、複数種の洗濯機のそれぞれに適用可能なルールであって、所定の２以上のブロックの１つが実行される場合にその所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止する。つまり、ルールは、上記実施の形態１～４と同様、所定の２以上のブロックの組み合わせに関する要件を示す。以下、所定の２以上のブロックの組み合わせは、単に、組み合わせとも呼ばれ、その組み合わせに関する要件は、組み合わせルールとも呼ばれる。汎用ルールＲ４００は、複数の組み合わせルールを示していてもよい。例えば、汎用ルールＲ４００は、第１の組み合わせルールと、第２の組み合わせルールとを示す。第１の組み合わせルールは、第１のブロックである排水の機能ブロックと、第２のブロックである脱水の機能ブロックに対する要件である。つまり、その第１の組み合わせルールは、脱水ブロックが実行される前に排水ブロックが実行されないことが禁止されることを示す。また、第２の組み合わせルールは、第２のブロックである乾燥の機能ブロックと、第３のブロックである送風の機能ブロックに対する要件である。つまり、その第２の組み合わせルールは、乾燥ブロックの後に送風ブロックが実行されないことが禁止されることを示す。

なお、排水ブロックは、機能として排水を洗濯機に実行させる機能ブロックであり、脱水ブロックは、機能として脱水を洗濯機に実行させる機能ブロックである。同様に、乾燥ブロックは、機能として乾燥を洗濯機に実行させる機能ブロックであり、送風ブロックは、機能として送風を洗濯機に実行させる機能ブロックである。

また、汎用ルールＲ４００が適用される複数種の洗濯機は、複数の製造業者から提供されている洗濯機を含む。また、各製造業者が複数の型式の洗濯機を提供していれば、その複数種の洗濯機は、その複数の型式の洗濯機を含む。つまり、汎用ルールＲ４００に示される組み合わせは、製造業者および型式を問わず、どのような洗濯機にも適用される。

また、その洗濯機の汎用ルールＲ４００は、図２１の（ｂ）に示すように、複数の製造業者のそれぞれの洗濯機に適用される組み合わせルールを示していてもよい。例えば、汎用ルールＲ４００は、製造業者「Ａ社」から提供される複数の型式の洗濯機に適用される組み合わせルールと、製造業者「Ｂ社」から提供される複数の型式の洗濯機に適用される組み合わせルールとなどを示す。

このように、本実施の形態におけるルールは、実施の形態１～４と同様、所定の２以上のブロックの１つが実行される場合にその所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止するルールである。そして、その所定の２以上のブロックは、第１のブロック及び第２のブロックを含み、ルールは、第２のブロックが実行される前に、第１のブロックが実行されないことを禁止する。すなわち、ルールは、アプリケーションの開始から第２のブロックが実行される前までに、第１のブロックが実行されないことを禁止する。このような第１のブロックは、実施の形態１～４と同様、第２のブロックを実行可能な環境に設定するためのブロックである。

あるいは、所定の２以上のブロックは、第２のブロック及び第３のブロックを含み、ルールは、第２のブロックが実行された後に、第３のブロックが実行されないことを禁止する。すなわち、ルールは、第２のブロックが実行された後からアプリケーションの終了までに、第３のブロックが実行されないことを禁止する。このような第３のブロックは、実施の形態１～４と同様、第２のブロックの実行により変化した環境を第２のブロックの実行前の環境に戻すためのブロックである。

なお、本実施の形態におけるルールは、実施の形態１～４と同様、例えば筐体２１の内部空間、アクチュエータ２２又は加熱器２３を耐久温度に到達させないために所定の２以上のブロックが組み合わせて実行されることを担保するためのルールであってもよい。

［５．２ 処理］
図２２は、情報処理システム２０００のシーケンス図である。

（ステップＳ１１）
まず、開発ツール５０は、１つ以上の機能ブロックをインストールする。具体的には、開発ツール５０は、ブロックデータベース４１から１つ以上の機能ブロックをダウンロードによって取得する。例えば、開発ツール５０は、オーブンレンジのブロック一覧４１ａを取得してもよく、そのブロック一覧４１ａの一部の機能ブロックのみを取得してもよい。そして、開発ツール５０は、その取得された１以上の機能ブロックを、シーケンスの生成に利用可能な状態にする。

ここで、ブロックデータベース４１に格納されている各機能ブロックには、その機能ブロックに対応するデバイス情報が付加されていてもよい。このデバイス情報は、そのデバイス情報に対応する機能ブロックに応じて駆動する例えば装置２０の製造業者、種別、型式、または型番などを示す。したがって、開発ツール５０は、それらのデバイス情報に基づいて、１つ以上の機能ブロックをダウンロードしてもよい。例えば、開発ツール５０は、同一の製造業者から提供されている各装置２０を駆動するための１つ以上の機能ブロックをダウンロードしてもよく、調理の温めに用いられる各装置２０を駆動するための１つ以上の機能ブロックをダウンロードしてもよい。

（ステップＳ１２）
次に、開発ツール５０は、シーケンスを生成する。具体的には、開発ツール５０は、操作者による入力部５４への入力操作に応じて、ダウンロード済みの１以上の機能ブロックを用いてシーケンスを生成する。なお、操作者は、シーケンスであるアプリケーションの開発者であってもよい。本実施の形態では、開発ツール５０は、このステップＳ１２において、上述のルールを参照し、そのルールに基づいてアプリケーションを変更する。

（ステップＳ１３）
次に、開発ツール５０は、生成されたシーケンスのアップロードを行う。具体的には、開発ツール５０は、操作者による入力部５４への入力操作に応じて、生成されたシーケンスをアプリ提供サーバ６０に送信するための送信情報を、そのシーケンスの内容に基づいて生成し、その送信情報をアプリ提供サーバ６０に送信する。この送信情報は、例えばＪＳＯＮ（JavaScript Object Notation）などであってもよい。これにより、そのシーケンスがアプリ提供サーバ６０に送信されて、アプリケーションとしてアプリ提供サーバ６０に格納される。

（ステップＳ１４）
次に、端末３０のユーザは、その端末３０のＵＩ４００を操作することによって、アプリ提供サーバ６０にアクセスし、アプリ提供サーバ６０に格納されているアプリケーションの一覧を閲覧する。そして、ＵＩ４００は、そのユーザによる操作に応じて、一覧からアプリケーションを選択し、そのアプリケーションのダウンロードをアプリ提供サーバ６０に要求する。

（ステップＳ１５）
アプリ提供サーバ６０は、ＵＩ４００からのダウンロードの要求を受け付けると、そのユーザに紐づくシーケンスマネージャ１００に、選択されたアプリケーションをダウンロードする。

図２３は、開発ツール５０の全体的な処理動作を示すフローチャートである。具体的には、図２３に示すフローチャートは、図２２のシーケンスにおけるステップＳ１１およびＳ１２の詳細な処理動作を示す。

（ステップＳ２１）
開発ツール５０は、まず、例えば洗濯機などの装置２０を駆動するための複数の機能ブロックをインストールする。

（ステップＳ２２）
次に、開発ツール５０は、操作者による入力部５４への入力操作に応じて、機能ブロックの配置処理を行う。すなわち、開発ツール５０は、ステップＳ２１でインストールされた複数の機能ブロックをディスプレイ５３に表示し、操作者による入力部５４への入力操作に応じて、その表示されている複数の機能ブロックから、１つの機能ブロックを選択する。そして、開発ツール５０は、操作者による入力部５４への入力操作に応じて、その機能ブロックをディスプレイ５３上のシーケンス生成画面における選択ブロック領域に配置する。シーケンス生成画面については、図２６を用いて後述する。つまり、操作者は、複数の機能ブロックのうちの１つの機能ブロックをその選択ブロック領域にドラッグ＆ドロップする。

（ステップＳ２３）
次に、開発ツール５０は、操作者による入力部５４への入力操作に応じて、ステップＳ２２で配置された機能ブロックのパラメータ設定処理を行う。すなわち、開発ツール５０は、上述のシーケンス生成画面におけるパラメータ設定領域に、その機能ブロックに用いられるパラメータの内容を受け付けるための受付画像を表示する。そして、開発ツール５０は、操作者による入力部５４への入力操作に応じて、そのパラメータの内容を受け付けて、そのパラメータの内容をパラメータ設定領域に表示する。これにより、その機能ブロックに対してパラメータが設定される。

（ステップＳ２４）
次に、開発ツール５０は、洗濯機などの装置２０に適用されるパラメータルールを参照し、そのステップＳ２３で設定されたパラメータが、そのパラメータルールに示されるパラメータ範囲外、すなわち非許容範囲外であるか否かを判定する。

（ステップＳ２５）
開発ツール５０は、ステップＳ２４でパラメータが非許容範囲外ではないと判定すると（ステップＳ２４のＮｏ）、パラメータ設定サポート処理を行う。このパラメータ設定サポート処理では、開発ツール５０は、操作者にエラーを提示するエラー提示処理、または、パラメータの自動修正処理を行う。パラメータの自動修正処理では、開発ツール５０は、非許容範囲のパラメータを許容範囲内のパラメータに変更することによって、その機能ブロックを変更する。エラー提示処理では、開発ツール５０は、例えば、直前のステップＳ２３で設定されたパラメータが非許容範囲内であることを示すメッセージをエラーとしてディスプレイ５３に表示し、そのパラメータの変更を操作者に促す。そして、開発ツール５０は、ステップＳ２５の処理が行われた後には、ステップＳ２３からの処理を繰り返し行う。

なお、ステップＳ２５においてパラメータの自動修正処理が行われた後に、ステップＳ２３の処理が行われる場合には、そのステップＳ２３では、開発ツール５０は、その自動修正処理によって変更された後のパラメータをパラメータ設定領域に表示する。一方、ステップＳ２５においてエラー提示処理が行われた後に、ステップＳ２３の処理が行われる場合には、そのステップＳ２３では、開発ツール５０は、上述と同様、再び、操作者による入力部５４への入力操作に応じて、そのパラメータの内容を受け付ける。これにより、その機能ブロックに対してパラメータが変更される。つまり、機能ブロックが変更される。

（ステップＳ２６）
開発ツール５０は、ステップＳ２４でパラメータが非許容範囲外であると判定すると（ステップＳ２４のＹｅｓ）、さらに、そのステップＳ２２で配置された機能ブロックの接続が許可されている否かを判定する。例えば、ステップＳ２２では、選択ブロック領域に既に配置されている他の機能ブロックである既存ブロックの直前または直後に、機能ブロックが配置される。その結果、機能ブロックは、その既存ブロックに接続された状態で配置される。つまり、機能ブロックによる装置２０の処理と、既存ブロックによる装置２０の処理とが連続して実行されるように、その機能ブロックが配置される。この場合、開発ツール５０は、洗濯機などの装置２０に適用される接続ルールを参照することによって、その機能ブロックと既存ブロックとの接続が許可されているか否かを判定する。

（ステップＳ２７）
開発ツール５０は、ステップＳ２６で接続が許可されていないと判定すると（ステップＳ２６のＮｏ）、接続サポート処理を行う。この接続サポート処理では、開発ツール５０は、操作者にエラーを提示するエラー提示処理、または、接続の自動修正処理を行う。そして、開発ツール５０は、ステップＳ２２からの処理を繰り返し行う。

なお、ステップＳ２７において接続の自動修正処理が行われた後に、ステップＳ２２の処理が行われる場合には、そのステップＳ２２では、開発ツール５０は、その自動修正処理によって接続し直された２以上の機能ブロックを選択ブロック領域に表示する。一方、ステップＳ２７においてエラー提示処理が行われた後に、ステップＳ２２の処理が行われる場合には、そのステップＳ２２では、開発ツール５０は、上述と同様、再び、操作者による入力部５４への入力操作に応じて、機能ブロックを配置し直す。また、ステップＳ２７からステップＳ２２の処理が繰り返される場合には、開発ツール５０は、機能ブロックのパラメータは既に許容範囲内に設定されているため、ステップＳ２２以降のステップＳ２３～Ｓ２５の処理をスキップしてもよい。

（ステップＳ２８）
開発ツール５０は、ステップＳ２６で接続が許可されていると判定すると（ステップＳ２６のＹｅｓ）、さらに、操作者による入力部５４への入力操作に応じて、シーケンスの生成が完了したか否かを判定する。ここで、開発ツール５０は、シーケンスの生成が完了していないと判定すると（ステップＳ２８のＮｏ）、ステップＳ２２からの処理を繰り返し行う。このときには、開発ツール５０は、ステップＳ２１でインストールされた複数のブロックから新たなブロックを、操作者による入力部５４への入力操作に応じて選択して、上述の選択ブロック領域に配置する。

（ステップＳ２９）
開発ツール５０は、ステップＳ２８でシーケンスの生成が完了したと判定すると（ステップＳ２８のＹｅｓ）、さらに、生成されたシーケンス全体の流れが許可されているか否かを判定する。例えば、そのシーケンスの中で、第１の機能ブロックよりも前または後に第２の機能ブロックが配置されている。一方、洗濯機などの装置２０に適用される組み合わせルールでは、その第１の機能ブロックと第２の機能ブロックとの組み合わせは、許可されていない。このような場合、開発ツール５０は、その生成されたシーケンス全体の流れが許可されていないと判定する。あるいは、洗濯機などの装置２０に適用される組み合わせルールでは、その第１の機能ブロックよりも前または後には、第２の機能ブロックが配置されていることが求められている。このような場合、開発ツール５０は、その生成されたシーケンス全体の流れが許可されていると判定する。

つまり、開発ツール５０は、洗濯機などの装置２０に適用されるルールを参照し、そのステップＳ２８で生成されたシーケンス、すなわちアプリケーションに含まれる複数の機能ブロックがそのルールに該当するか否かを判定する。そして、開発ツール５０は、その複数の機能ブロックがルールに該当していれば、ステップＳ２８で生成されたシーケンス全体の流れが許可されていないと判定する。一方、開発ツール５０は、その複数の機能ブロックがルールに該当していなければ、ステップＳ２８で生成されたシーケンス全体の流れは許可されていると判定する。なお、ステップＳ２９で参照されるルールは、装置２０に適用される上述の汎用ルールまたは専用ルールであり、より具体的には、そのルールに含まれる組み合わせルールである。また、ルールに該当するか否かの判定方法は、上記実施の形態１～４と同様である。

（ステップＳ３０）
開発ツール５０は、ステップＳ２９でシーケンス全体の流れが許可されていないと判定すると（ステップＳ２９のＮｏ）、配置サポート処理を行う。この配置サポート処理では、開発ツール５０は、操作者にエラーを提示する配置のエラー提示処理、または、機能ブロックの配置の自動修正処理を行う。そして、開発ツール５０は、ステップＳ２２からの処理を繰り返し行う。

なお、ステップＳ３０において配置の自動修正処理が行われた後に、ステップＳ２２の処理が行われる場合には、そのステップＳ２２では、開発ツール５０は、その自動修正処理によって配置し直された２以上の機能ブロックを選択ブロック領域に表示する。また、ステップＳ３０からステップＳ２２の処理が繰り返される場合には、開発ツール５０は、機能ブロックのパラメータは既に許容範囲内に設定されているため、ステップＳ２２以降のステップＳ２３～Ｓ２５の処理をスキップしてもよい。また、開発ツール５０は、機能ブロックの接続は既に許可されているため、ステップＳ２６およびＳ２７の処理をスキップしてもよい。さらに、開発ツール５０は、ステップＳ２８の処理もスキップしてもよい。

図２４は、配置の自動修正処理の一例を示すフローチャートである。

（ステップＳ４１）
開発ツール５０は、操作者による入力部５４への入力操作に応じて、例えば洗濯機などの装置２０を駆動するためのＮ個（Ｎは２以上の整数）の機能ブロックからＭ個（Ｍは２以上かつＮ以下の整数）の機能ブロックを選択する。つまり、開発ツール５０は、制御対象機器である装置２０に備えられているアクチュエータ２２及び加熱器２３の少なくとも１つを駆動するためのＮ個の機能ブロックから、操作者による入力部５４への入力操作に応じて、Ｍ個の機能ブロックのそれぞれを選択ブロックとして選択する。

（ステップＳ４２）
次に、開発ツール５０は、選択されたＭ個の機能ブロックのそれぞれを、上述の選択ブロック領域に順序付けて配置することによって、シーケンス、すなわちアプリケーションを生成する。つまり、開発ツール５０は、少なくともＭ個の選択ブロックのそれぞれが実行される順番を、操作者による入力部５４への入力操作に応じて設定することで、少なくともＭ個の選択ブロックを含むアプリケーションを生成する。なお、このアプリケーションに含まれるＭ個の選択ブロックのそれぞれは、アクチュエータ２２及び加熱器２３の少なくとも１つを駆動するためのパラメータを含んでいてもよい。

（ステップＳ４３）
次に、開発ツール５０は、Ｍ個の機能ブロックのそれぞれが洗濯機を駆動するためのブロックであれば、洗濯機に適用されるルールを参照する。例えば、開発ツール５０は、ステップＳ４２で生成されたアプリケーションが複数種の洗濯機に適用される場合には、汎用ルールＲ４００を参照する。また、開発ツール５０は、ステップＳ４２で生成されたアプリケーションが所定の型式の洗濯機に適用される場合には、専用ルールＲ４１～Ｒ４３のうちのその型式の洗濯機に対応付けられているルールを参照する。つまり、開発ツール５０は、ステップＳ４２で生成されるアプリケーションが、制御対象機器専用のアプリケーションか、その制御対象機器と、その制御対象機器以外の機器とに適用される汎用のアプリケーションかを判定する。そして、開発ツール５０は、所定の２以上のブロックの１つが実行される場合にその所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止する複数のルール候補のうちの、そのアプリケーションの判定結果に応じたルール候補を、上述のルールとして参照する。

（ステップＳ４４）
そして、開発ツール５０は、ステップＳ４２で設定されたＭ個の機能ブロックが、上述のルールに該当するか否かを判定する。つまり、開発ツール５０は、アプリケーションに含まれるＭ個の機能ブロックが、そのルールに含まれる組み合わせルールに該当するか否かを判定する。

（ステップＳ４５）
ここで、開発ツール５０は、そのＭ個の機能ブロックがルールに該当すると判定すると（ステップＳ４４のＹｅｓ）、そのアプリケーションを変更する。つまり、開発ツール５０は、所定の２以上のブロックの１つが実行される場合にその所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止するルールを参照して、アプリケーションに含まれるＭ個の選択ブロックがそのルールに該当する場合、そのアプリケーションを変更する。具体的には、開発ツール５０は、（１）Ｍ個の選択ブロックに新たなブロックを追加し、（２）Ｍ個の選択ブロックの順番を変更し、又は、（３）Ｍ個の選択ブロックのうちいずれかのブロックを削除することで、そのアプリケーションを変更する。これらのアプリケーションの変更方法は、ルールに定義されていてもよい。

（ステップＳ４６）
そして、開発ツール５０は、変更したアプリケーションを出力する。

図２５は、配置のエラー提示処理の一例を示すフローチャートである。

（ステップＳ４１～Ｓ４４）
開発ツール５０は、図２４に示す例と同様、ステップＳ４１～Ｓ４４の処理を実行する。

（ステップＳ５１）
開発ツール５０は、ステップＳ４４でＭ個の機能ブロックがルールに該当すると判定すると（ステップＳ４４のＹｅｓ）、そのアプリケーションを自動的に変更することなく、ディスプレイ５３にエラーを表示する。これにより、操作者にエラーが提示される。つまり、ステップＳ４３、Ｓ４４およびＳ５１の処理では、開発ツール５０は、ルールを参照することによって、エラーを提示する。具体的には、開発ツール５０は、所定の２以上のブロックの１つが実行される場合に所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止するルールを参照して、そのアプリケーションに含まれるＭ個の選択ブロックがそのルールに該当する場合、操作者に対してエラーを提示する。

なお、開発ツール５０は、エラーを提示するとともに、操作者に対して、複数の対処法を示し、操作者に対して対処法の選択を促しても良い。その際、開発ツール５０は、複数の対処法のそれぞれについて、出力性能の違いを操作者に対して提示してもよい。また、その際、開発ツール５０は、新たな機能ブロックの追加による第１の対処法と、Ｍ個の選択ブロックの順番を変更する第２の対処法と、何れかの機能ブロックを削除するする第３の対処法のうち、少なくとも二つ以上の対処法を提示してもよい。これにより、それらの対処法が、例えばアプリケーション開発者である操作者に提示される。その結果、それらの対処法を見たアプリケーション開発者である操作者は、開発ツール５０の入力部５４への入力操作を行うことによって、ステップＳ４２で生成されたアプリケーションを、その対処法にしたがって容易に変更することができる。

（ステップＳ５２）
そのエラーを見た操作者は、開発ツール５０の入力部５４への入力操作を行うことによって、ステップＳ４２で生成されたアプリケーションを変更する。また、操作者に対して複数の対処法のそれぞれが選択肢として提示されている場合は、操作者は、入力操作を行うことによって、それらの選択肢の中から任意の対処法を選択する。その結果、開発ツール５０は、アプリケーションを変更する。つまり、開発ツール５０は、エラーの提示を受けた操作者による入力操作に応じて、アプリケーションを変更する。そして、開発ツール５０は、ステップＳ４３からの処理を繰り返し実行する。

（ステップＳ４６）
開発ツール５０は、ステップＳ４４において、Ｍ個の機能ブロックがルールに該当していないと判定すると（ステップＳ４４のＮｏ）、アプリケーションを出力する。このとき、ステップＳ５２でアプリケーションが変更されていれば、変更されたアプリケーションが出力される。一方、ステップＳ５２でアプリケーションが変更されていなければ、ステップＳ４２で生成されたアプリケーションが出力される。

なお、ステップＳ５１の処理が繰り返される場合に、開発ツール５０は、その繰り返しの回数に応じて、エラーへの対処法を提示してもよい。例えば、開発ツール５０は、エラーの提示回数がＫ回（Ｋは２以上の整数）以上の場合には、そのエラーに対する複数の対処法を提示してもよい。つまり、開発ツール５０は、エラーの提示回数がＫ回以上の場合には、上述の第１の対処法、第２の対処法、および第３の対処法のうちの少なくとも２つを操作者に提示する。

［５．３ 表示例］
図２６は、シーケンス生成画面の一例を示す図である。

開発ツール５０は、上述のシーケンス生成画面をディスプレイ５３に表示する。シーケンス生成画面は、パラメータ設定領域Ｄ１と、ブロック一覧領域Ｄ２と、対象装置領域Ｄ３と、選択ブロック領域Ｄ４とを含む。

パラメータ設定領域Ｄ１には、機能ブロックに用いられるパラメータの内容を受け付けるための受付画像が表示される。

ブロック一覧領域Ｄ２には、複数種の装置２０のそれぞれのブロック一覧が表示される。これらのブロック一覧は、ブロックデータベース４１からダウンロードされて開発ツール５０にインストールされた機能ブロックを含む。

対象装置領域Ｄ３には、複数種の装置２０から選択された装置２０の種別名が表示される。

選択ブロック領域Ｄ４には、ブロック一覧領域Ｄ２に表示されるブロック一覧から選択された機能ブロックが配置されて表示される。その機能ブロックは、例えばアイコンとして表示される。

例えば、操作者は、開発ツール５０の入力部５４に対する入力操作を行うことによって、アプリケーションが適用される装置２０の種別名を決定する。開発ツール５０は、その決定された種別名を対象装置領域Ｄ３に表示する。例えば、その決定された種別名「炊飯器」が表示される。続いて、操作者は、入力操作を行うことによって、ブロック一覧領域Ｄ２に表示されるブロック一覧から、決定された種別名「炊飯器」の装置２０を駆動するための機能ブロックを選択する。そして、操作者は、入力操作を行うことによって、選択された機能ブロック、すなわち選択ブロックを選択ブロック領域Ｄ４に配置する。この機能ブロックの選択および配置は、ドラッグ＆ドロップによって行われてもよい。この選択ブロック領域Ｄ４に配置される１つ以上の機能ブロックは、その配置されている順に実行されてもよい。例えば、図２６における左側から右側に向かって、それらの機能ブロックが順に実行される。つまり、アプリケーションは、その選択ブロック領域Ｄ４に配置されるＭ個の選択ブロックのそれぞれが実行される順番の情報と、そのＭ個の選択ブロックのそれぞれが実行されるタイミングの情報とを含む。

機能ブロックが選択ブロック領域Ｄ４に配置されると、開発ツール５０は、パラメータ設定領域Ｄ１に、その機能ブロックに用いられるパラメータの受付画像を表示する。

図２７は、ブロック一覧の表示例を示す図である。

操作者は、図２６に示すブロック一覧領域Ｄ２に表示されている複数の装置２０のそれぞれの種別名のうち、これから生成するアプリケーションが適用される装置２０の種別名を、入力部５４に対する入力操作を行うことによって選択する。開発ツール５０は、その選択された種別名の装置２０に対応するブロック一覧を、例えば図２７の（ａ）および（ｂ）に示すように表示する。例えば、図２７の（ａ）に示すように、オーブンレンジが選択されると、開発ツール５０は、そのオーブンレンジのブロック一覧を表示する。例えば、そのブロック一覧は、焼き、レンジ加熱、オーブン、グリル、蒸し、予熱、および過熱水蒸気のそれぞれの機能を実現する機能ブロックを含む。また、図２７の（ｂ）に示すように、マルチクッカーが選択されると、開発ツール５０は、そのマルチクッカーのブロック一覧を表示する。例えば、そのブロック一覧は、予熱、保温、炒め、圧力調理、炊き、蒸し、煮込み、混ぜる、および、ゆでるのそれぞれの機能を実現する機能ブロックを含む。

操作者は、入力部５４への入力操作を行うことによって、このように表示されるブロック一覧から機能ブロックを選択し、その選択された機能ブロックを、図２６に示す選択ブロック領域Ｄ４に配置する。つまり、開発ツール５０は、このような入力操作に応じて、図２３に示すステップＳ２２の処理、すなわち機能ブロックの配置処理を行う。

図２８Ａは、機能ブロックの配置処理と、配置の自動修正処理の一例を示す図である。

開発ツール５０は、例えば図２８Ａの（ａ）に示すように、ブロック一覧からドラッグ＆ドロップされて選択ブロック領域Ｄ４に配置された機能ブロックを例えばアイコンとして表示する。具体的には、開発ツール５０は、操作者による入力部５４に対する入力操作に応じて、脱水の機能ブロックＦＢ４２を含むＭ個の機能ブロックを選択ブロック領域Ｄ４に配置する。このように、開発ツール５０は、操作者の入力操作に応じて、図２３に示すステップＳ２２の機能ブロックの配置処理を行う。

また、開発ツール５０は、機能ブロックの配置処理の結果、アプリケーションが生成されると、図２３のステップＳ２９のように、そのアプリケーション全体の流れが許可されているか否かを判定する。すなわち、開発ツール５０は、選択ブロック領域Ｄ４に配置されているＭ個の機能ブロックに対する判定を、ルールを用いて行う。そして、開発ツール５０は、その配置の自動修正処理を行う。

具体的には、開発ツール５０は、まず、それらのＭ個の機能ブロックに対応する洗濯機のルールを参照する。例えば、開発ツール５０は、図２０の（ｂ）に示すルールデータベース４２のうちの、洗濯機のルール群４２ｄを特定し、そのルール群４２ｄに含まれる何れか１つのルールを参照する。そのルールは、汎用ルールＲ４００であっても、専用ルールＲ４１などであってもよい。例えば、ルールは、第２のブロックである脱水の機能ブロックＦＢ４２が実行される前に、第１のブロックである排水の機能ブロックＦＢ４１が実行されないことを禁止する組み合わせルールを含む。

そして、開発ツール５０は、配置されているＭ個の機能ブロックがそのルールに該当すると判定すると、アプリケーションを変更する。例えば、開発ツール５０は、図２８Ａの（ｂ）に示すように、機能ブロックＦＢ４２の前に排水の機能ブロックＦＢ４１を追加することによって、洗濯機のアプリケーションを変更する。

このように、本実施の形態では、開発ツール５０は、アプリケーションが第２のブロックを含み、かつ、第２のブロックの前に第１のブロックを含まない場合に、第２のブロックの前に、第１のブロックを追加することで、そのアプリケーションを変更する。このような変更によって、Ｍ個の機能ブロックはルールに該当しない状態になる。

また、機能ブロックの配置処理によって、第１のブロックである排水の機能ブロックＦＢ４１が第２のブロックである脱水の機能ブロックＦＢ４２よりも後に配置されている場合には、開発ツール５０は、その排水の機能ブロックＦＢ４１を前に移動させてもよい。つまり、開発ツール５０は、アプリケーションが、第１のブロック及び第２のブロックを含み、かつ、第２のブロックの前に第１のブロックを含まない場合に、その第１のブロックの順番を第２のブロックの順番よりも前に変更することで、アプリケーションを変更する。このような変更によっても、Ｍ個の機能ブロックはルールに該当しない状態になる。

また、開発ツール５０は、第２のブロックである脱水の機能ブロックＦＢ４２を削除してもよい。つまり、開発ツール５０は、アプリケーションが第２のブロックを含み、かつ、第２のブロックの前に第１のブロックを含まない場合に、その第２のブロックを削除することで、アプリケーションを変更する。このような変更によっても、Ｍ個の機能ブロックはルールに該当しない状態になる。

図２８Ｂは、機能ブロックの配置処理と、配置の自動修正処理の他の例を示す図である。

開発ツール５０は、例えば図２８Ｂの（ａ）に示すように、ブロック一覧からドラッグ＆ドロップされて選択ブロック領域Ｄ４に配置された機能ブロックを例えばアイコンとして表示する。具体的には、開発ツール５０は、操作者による入力部５４に対する入力操作に応じて、乾燥の機能ブロックＦＢ４４を含むＭ個の機能ブロックを選択ブロック領域Ｄ４に配置する。このように、開発ツール５０は、操作者の入力操作に応じて、図２３に示すステップＳ２２の機能ブロックの配置処理を行う。

また、開発ツール５０は、機能ブロックの配置処理の結果、アプリケーションが生成されると、図２３のステップＳ２９のように、そのアプリケーション全体の流れが許可されているか否かを判定する。すなわち、開発ツール５０は、選択ブロック領域Ｄ４に配置されているＭ個の機能ブロックに対する判定を、ルールを用いて行う。そして、開発ツール５０は、その配置の自動修正処理を行う。

具体的には、開発ツール５０は、まず、それらのＭ個の機能ブロックに対応する洗濯機のルールを参照する。例えば、開発ツール５０は、図２０の（ｂ）に示すルールデータベース４２のうちの、洗濯機のルール群４２ｄを特定し、そのルール群４２ｄに含まれる何れか１つのルールを参照する。そのルールは、汎用ルールＲ４００であっても、専用ルールＲ４１などであってもよい。例えば、ルールは、第２のブロックである乾燥の機能ブロックＦＢ４４が実行された後に、第３のブロックである送風の機能ブロックＦＢ４５が実行されないことを禁止する組み合わせルールを含む。

そして、開発ツール５０は、配置されているＭ個の機能ブロックがそのルールに該当すると判定すると、アプリケーションを変更する。例えば、開発ツール５０は、図２８Ｂの（ｂ）に示すように、機能ブロックＦＢ４４の後に送風の機能ブロックＦＢ４５を追加することによって、洗濯機のアプリケーションを変更する。

このように、本実施の形態では、開発ツール５０は、アプリケーションが第２のブロックを含み、かつ、第２のブロックの後に第３のブロックを含まない場合に、第２のブロックの後に、第３のブロックを追加することで、アプリケーションを変更する。このような変更によって、Ｍ個の機能ブロックはルールに該当しない状態になる。

また、機能ブロックの配置処理によって、第３のブロックである送風の機能ブロックＦＢ４５が第２のブロックである乾燥の機能ブロックＦＢ４４よりも前に配置されている場合には、開発ツール５０は、その送風の機能ブロックＦＢ４５を後に移動させてもよい。つまり、開発ツール５０は、アプリケーションが、第２のブロック及び第３のブロックを含み、かつ、第２のブロックの後に第３のブロックを含まない場合に、第３のブロックの順番を第２のブロックの順番よりも後に変更することで、そのアプリケーションを変更する。このような変更によっても、Ｍ個の機能ブロックはルールに該当しない状態になる。

また、開発ツール５０は、第２のブロックである乾燥の機能ブロックＦＢ４４を削除してもよい。つまり、開発ツール５０は、アプリケーションが第２のブロックを含み、かつ、第２のブロックの後に第３のブロックを含まない場合に、第２のブロックを削除することで、そのアプリケーションを変更する。このような変更によっても、Ｍ個の機能ブロックはルールに該当しない状態になる。

図２８Ａおよび図２８Ｂのように、本実施の形態では、配置の自動修正処理が行われる。したがって、アプリケーション開発者である操作者が、Ｍ個の機能ブロックを誤ってルールに該当するように配置しても、そのＭ個の機能ブロックは、ルールに該当しないように自動的に配置し直される。したがって、洗濯機の安全性を担保することができる。

図２９は、配置のエラー提示処理の一例を示す図である。

開発ツール５０は、図２８Ａの例と同様、図２９に示すように、脱水の機能ブロックＦＢ４２を含むＭ個の機能ブロックを選択ブロック領域Ｄ４に配置する。また、開発ツール５０は、その配置の結果、アプリケーションが生成されると、図２３のステップＳ２９のように、そのアプリケーション全体の流れが許可されているか否かを判定する。すなわち、開発ツール５０は、選択ブロック領域Ｄ４に配置されているＭ個の機能ブロックに対する判定を、ルールを用いて行う。例えば、ルールは、第２のブロックである脱水の機能ブロックＦＢ４２が実行される前に、第１のブロックである排水の機能ブロックＦＢ４１が実行されないことを禁止する組み合わせルールを含む。

そして、開発ツール５０は、そのＭ個の機能ブロックがルールに該当すると判定すると、エラー提示処理を行う。具体的には、開発ツール５０は、図２９に示すように、エラーメッセージＥ１をエラーとして表示する。このエラーメッセージＥ１には、脱水の機能ブロックＦＢ４２に対応する機能ブロックが前に配置されていないことが記されている。つまり、このエラーメッセージＥ１は、第２のブロックである脱水の機能ブロックＦＢ４２が実行される前に、第１のブロックである排水の機能ブロックＦＢ４１が実行されないことを禁止するルールに、Ｍ個の機能ブロックが該当していることを、通知している。このようなエラー提示処理は、例えば図２５のステップＳ５１において行われる。

このように、本実施の形態では、開発ツール５０は、所定の２以上のブロックの１つが実行される場合にその所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止するルールを参照して、そのアプリケーションに含まれるＭ個の選択ブロックがルールに該当する場合、操作者に対してエラーを提示する。そして、開発ツール５０は、そのエラーの提示を受けた操作者による入力操作に応じて、Ｍ個の選択ブロックのそれぞれが実行される順番を変更することでアプリケーションを変更する。

このようなエラーが提示されることによって、アプリケーション開発者である操作者は、ルールに該当するＭ個の機能ブロックを、そのルールに該当しないように、容易に配置し直すことができる。したがって、洗濯機の安全性を担保することができる。

また、開発ツール５０は、エラー提示処理では、さらに、そのエラーメッセージＥ１によって示されるエラーに対処するための対処法Ｃ１およびＣ２を表示してもよい。この対処法Ｃ１には、脱水の機能ブロックの前に、排水の機能ブロックを追加することによってエラーが解消されることが記されている。つまり、対処法Ｃ１は、Ｍ個の選択ブロックに新たなブロックを追加する上述の第１の対処法である。さらに、開発ツール５０は、その対処法Ｃ１を行うことによって受ける影響を、その対処法Ｃ１と共に表示してもよい。例えば、開発ツール５０は、洗濯の全行程にかかる処理時間が長くなるが、脱水が適切に行われることを影響として表示してもよい。

また、対処法Ｃ２には、脱水の機能ブロックを削除することによってエラーが解消されることが記されている。つまり、対処法Ｃ２は、Ｍ個の選択ブロックのうちいずれかのブロックを削除する第３の対処法である。さらに、開発ツール５０は、その対処法Ｃ２を行うことによって受ける影響を、その対処法Ｃ２と共に表示してもよい。例えば、開発ツール５０は、脱水を行うことができないが、洗濯機の安全性を担保することができることを影響として表示してもよい。

図３０は、接続のエラー提示処理の他の例を示す図である。

開発ツール５０は、図２８Ｂの例と同様、図３０に示すように、乾燥の機能ブロックＦＢ４４を含むＭ個の機能ブロックを選択ブロック領域Ｄ４に配置する。また、開発ツール５０は、その配置の結果、アプリケーションが生成されると、図２３のステップＳ２９のように、そのアプリケーション全体の流れが許可されているか否かを判定する。すなわち、開発ツール５０は、選択ブロック領域Ｄ４に配置されているＭ個の機能ブロックに対する判定を、ルールを用いて行う。例えば、ルールは、第２のブロックである乾燥の機能ブロックＦＢ４４が実行された後に、第３のブロックである送風の機能ブロックＦＢ４５が実行されないことを禁止する組み合わせルールを含む。

そして、開発ツール５０は、そのＭ個の機能ブロックがルールに該当すると判定すると、エラー提示処理を行う。具体的には、開発ツール５０は、図３０に示すように、エラーメッセージＥ２をエラーとして表示する。このエラーメッセージＥ２には、乾燥の機能ブロックＦＢ４４に対応する機能ブロックが後に配置されていないことが記されている。つまり、このエラーメッセージＥ２は、第２のブロックである乾燥の機能ブロックＦＢ４４が実行された後に、第３のブロックである送風の機能ブロックＦＢ４５が実行されないことを禁止するルールに、Ｍ個の機能ブロックが該当していることを、通知している。このようなエラー提示処理は、例えば図２５のステップＳ５１において行われる。

このようなエラーが提示されることによって、アプリケーション開発者である操作者は、ルールに該当するＭ個の機能ブロックを、そのルールに該当しないように、容易に配置し直すことができる。したがって、洗濯機の安全性を担保することができる。

また、開発ツール５０は、エラー提示処理では、さらに、そのエラーメッセージＥ２によって示されるエラーに対処するための対処法Ｃ３～Ｃ５を表示してもよい。この対処法Ｃ３には、乾燥の機能ブロックの後に、送風の機能ブロックを追加することによってエラーが解消されることが記されている。つまり、対処法Ｃ３は、Ｍ個の選択ブロックに新たなブロックを追加する上述の第１の対処法である。さらに、開発ツール５０は、その対処法Ｃ３を行うことによって受ける影響を、その対処法Ｃ３と共に表示してもよい。例えば、開発ツール５０は、洗濯の全行程にかかる処理時間が長くなるが、洗濯機の安全性を担保することができることを影響として表示してもよい。

また、対処法Ｃ４には、乾燥の機能ブロックの前に配置されている送風の機能ブロックを、乾燥の機能ブロックの後に移動させることによってエラーが解消されることが記されている。つまり、対処法Ｃ４は、Ｍ個の選択ブロックの順番を変更する上述の第２の対処法である。さらに、開発ツール５０は、その対処法Ｃ４を行うことによって受ける影響を、その対処法Ｃ４と共に表示してもよい。例えば、開発ツール５０は、洗濯機の安全性を担保することができることを影響として表示してもよい。

また、対処法Ｃ５には、乾燥の機能ブロックを削除することによってエラーが解消されることが記されている。つまり、対処法Ｃ５は、Ｍ個の選択ブロックのうちいずれかのブロックを削除する第３の対処法である。さらに、開発ツール５０は、その対処法Ｃ５を行うことによって受ける影響を、その対処法Ｃ５と共に表示してもよい。例えば、開発ツール５０は、乾燥を行うことができないが、洗濯機の安全性を担保することができることを影響として表示してもよい。

このように、本実施の形態では、開発ツール５０は、エラーに対する複数の対処法を提示する。そして、開発ツール５０は、そのエラーおよび複数の対処法の提示を受けた操作者による入力操作に応じて、アプリケーションを変更する。

例えば、その複数の対処法は、上述の第１の対処法、第２の対処法および第３の対処法のうちの少なくとも２つを含む。さらに、本実施の形態では、開発ツール５０は、複数の対処法のそれぞれが行われた場合における、アクチュエータ２２又は加熱器２３の駆動によって作用される物体への影響、またはアプリケーションへの影響を提示する。

このような複数の対処法と、それらの対処法による影響とが提示されることによって、アプリケーション開発者である操作者は、ルールに該当するＭ個の機能ブロックを、そのルールに該当しないように、さらに容易に配置し直すことができる。したがって、洗濯機の安全性を担保することができる。

なお、エラーメッセージＥ１およびＥ２と、対処法Ｃ１～Ｃ５とは、シーケンス生成画面のうちの何れの領域に表示されてもよい。また、これらのエラーメッセージＥ１およびＥ２と、対処法Ｃ１～Ｃ５とはそれぞれ、組み合わせルールに対応付けて示されていてもよい。また、上述の例では、エラーメッセージＥ１およびＥ２と、対処法Ｃ１～Ｃ５とが表示されるが、それらの提示形態はこれらの例に限らず、どのような形態であってもよい。例えば、音声でエラーなどが提示されてもよい。

また、開発ツール５０は、エラーの提示回数がＫ回（Ｋは２以上の整数）以上の場合には、エラーに対する複数の対処法を操作者に提示してもよい。つまり、開発ツール５０は、図２５に示すステップＳ５１の処理が繰り返される場合には、開発ツール５０は、その繰り返しの回数に応じて、エラーの提示形態を変更してもよい。具体的には、開発ツール５０は、エラーの提示回数がＫ回未満の場合には、エラーを提示して対処法を提示せず、エラーの提示回数がＫ回以上の場合には、エラーと共に対処法も表示する。

図３１は、対処法の他の提示例を示す図である。

上述の例では、対処法はメッセージとして提示されるが、開発ツール５０は、図３１に示すように、他の態様で対処法を提示してもよい。例えば、開発ツール５０は、エラーを回避するために追加すべき機能ブロックがブロック一覧から容易に選択され得る態様で、その対処法を提示する。つまり、開発ツール５０は、組み合わせルールに示される第２のブロックの前に第１のブロックが配置されていないと判定すると、図３２に示すように、ブロック一覧を表示する。このブロック一覧では、その第２のブロックの前に配置されるべき第１のブロックである機能ブロックのみが、そのブロック一覧に含まれる他の機能ブロックと異なる態様で表示される。具体的には、洗濯機のブロック一覧のうち、脱水の機能ブロックの前に追加すべき排水の機能ブロックのみが明るく表示され、他の機能ブロックは暗く表示される。これにより、アプリケーション開発者である操作者は、その排水の機能ブロックを容易に選択して選択ブロック領域Ｄ４に追加することができ、アプリケーションの変更の操作性を高めることができる。

図３２は、対処法のさらに他の提示例を示す図である。

上述の例では、対処法はメッセージのみで提示されるが、開発ツール５０は、図３２に示すように、矢印などのオブジェクトを用いて対処法を提示してもよい。例えば、開発ツール５０は、機能ブロックＦＢ３４と機能ブロックＦＢ３７とがルールに該当すると判定すると、それらの機能ブロックの順番を逆にする第２の対処法を、メッセージと矢印とで提示する。これにより、アプリケーション開発者である操作者は、それらの機能ブロックの順番を逆にしてエラーを容易に回避することができ、アプリケーションの変更の操作性を高めることができる。

［５．４ 効果など］
以上のように、本実施の形態では、ブロックを含むアプリケーションとルールデータベースとにより、多様多種でかつ安全なアプリケーションを開発可能な環境を提供することができる。したがって、その環境下で自由に開発したアプリケーションに対して、物理的に運動するアクチュエータ２２、又は熱エネルギーを出力する加熱器２３の安全な駆動することを可能にしている。その結果、例えば、自由度の高い多様多種なアプリケーションの開発と、安全性を担保するためのルールデータベースの開発とを並行して作成することが可能になり、多様多種でかつ安全なアプリケーションを早期に開発することを可能にすることができる。

また、本実施の形態と、実施の形態１～４のうちの何れかの形態とを組み合わせれば、アプリケーションの提供後においても、ルールデータベースを変更することで、より安全性を担保したアプリケーションへの変更も可能になる。また、事前に製造者が想定しない状況の改善が必要になった場合においても、多様多種なアプリケーション自体を変更せずとも、アプリケーションとは独立して、ルールデータベースが規定されているため、そのルールデータベースを更新することで、全てのアプリケーションへの対応が可能になる。

具体的には、本実施の形態における情報処理方法は、開発ツール５０のようなコンピュータシステムによって実行される情報処理方法である。そして、この情報処理方法では、（ａ）制御対象機器である装置２０に備えられているアクチュエータ２２及び加熱器２３の少なくとも１つを駆動するためのＮ個（Ｎは２以上の整数）のブロックから、操作者による入力操作に応じて、Ｍ個（Ｍは１以上かつＮ以下の整数）のブロックのそれぞれを選択ブロックとして選択し、（ｂ）少なくともそのＭ個の選択ブロックのそれぞれが実行される順番を、操作者による入力操作に応じて設定することで、少なくともそのＭ個の選択ブロックを含むアプリケーションを生成し、（ｃ）所定の２以上のブロックの１つが実行される場合にその所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止するルールを参照して、そのアプリケーションに含まれるＭ個の選択ブロックが上記ルールに該当する場合、そのアプリケーションを変更し、（ｄ）変更したアプリケーションを出力する。

これによれば、Ｍ個のブロックで規定されたアプリケーションに基づいてアクチュエータ２２及び／又は加熱器２３を駆動することができる。したがって、装置２０の制御を抽象化したブロックを用いたアプリケーションの開発が可能となり、多種多彩なアプリケーションを製造者だけではなく、サードパーティも開発することができ、これらのアプリケーションを装置２０で簡単に実行することが可能となる。さらに、この開発時には、上述のルールに該当するＭ個の選択ブロックを含むアプリケーションが自動的に変更される。その結果、そのアプリケーションを、ルールに該当しないＭ個の選択ブロックを含むアプリケーションに自動的に変更することができる。したがって、所定の２以上のブロックのうちの１つのブロックが残りの少なくとも１つのブロックと組み合わせて実行されることを担保することができる。つまり、もし、アプリケーション開発者である操作者が、単独での実行が許容されないブロックを単独で実行するように、アプリケーションを誤って生成した場合でも、装置２０を安全に制御することができないアプリケーションが生成されることを抑制することができる。したがって、アプリケーション開発者が、アクチュエータ２２及び／又は加熱器２３のユーザに適することを重視したアプリケーションを作成または生成した場合でも、そのアプリケーションで制御される装置２０の安全性を担保することができ、その安全性を向上させることができる。

また、上記（ｃ）では、（１）Ｍ個の選択ブロックに新たなブロックを追加し、（２）Ｍ個の選択ブロックの順番を変更し、又は、（３）Ｍ個の選択ブロックのうちいずれかのブロックを削除することで、アプリケーションを変更してもよい。

より具体的には、その所定の２以上のブロックは、第１のブロック及び第２のブロックを含み、ルールは、第２のブロックが実行される前に、第１のブロックが実行されないことを禁止する。そして、上記（ｃ）では、アプリケーションが第２のブロックを含み、かつ、第２のブロックの前に第１のブロックを含まない場合に、第２のブロックの前に、第１のブロックを追加することで、アプリケーションを変更してもよい。

また、上記（ｃ）では、アプリケーションが、第１のブロック及び第２のブロックを含み、かつ、第２のブロックの前に第１のブロックを含まない場合に、第１のブロックの順番を第２のブロックの順番よりも前に変更することで、アプリケーションを変更してもよい。

また、上記（ｃ）では、アプリケーションが第２のブロックを含み、かつ、第２のブロックの前に第１のブロックを含まない場合に、第２のブロックを削除することで、アプリケーションを変更してもよい。

これらによれば、アプリケーションの開発時に、新たなブロックを追加、ブロックの順番を変更、又は、ブロックを削除することで、第２のブロックの前に第１のブロックが実行されることを担保することができる。したがって、アプリケーションの開発者、または、アクチュエータ２２及び加熱器２３を制御する装置２０に組み込まれるソフトウェアの開発者は、アプリケーション一つ一つの安全性を毎回チェックすることなく、装置２０の安全性を担保することができる。

また、具体的には、上記ルールは、アプリケーションの開始から第２のブロックが実行される前までに、第１のブロックが実行されないことを禁止してもよい。さらに、第１のブロックは、第２のブロックを実行可能な環境に設定するためのブロックであってもよい。

また、上述の所定の２以上のブロックは、第２のブロック及び第３のブロックを含み、ルールは、第２のブロックが実行された後に、第３のブロックが実行されないことを禁止してもよい。この場合、上記（ｃ）では、アプリケーションが第２のブロックを含み、かつ、第２のブロックの後に第３のブロックを含まない場合に、第２のブロックの後に、第３のブロックを追加することで、アプリケーションを変更してもよい。

また、上記（ｃ）では、アプリケーションが、第２のブロック及び第３のブロックを含み、かつ、第２のブロックの後に第３のブロックを含まない場合に、第３のブロックの順番を第２のブロックの順番よりも後に変更することで、アプリケーションを変更してもよい。

また、上記前記（ｃ）では、アプリケーションが第２のブロックを含み、かつ、第２のブロックの後に第３のブロックを含まない場合に、第２のブロックを削除することで、アプリケーションを変更する。

これらによれば、アプリケーションの開発時に、新たなブロックを追加、ブロックの順番を変更、又は、ブロックを削除することで、第２のブロックの後に第３のブロックが実行されることを担保することができる。したがって、アプリケーションの開発者、または、アクチュエータ２２及び加熱器２３を制御する装置２０に組み込まれるソフトウェアの開発者は、アプリケーション一つ一つの安全性を毎回チェックすることなく、装置２０の安全性を担保することができる。

また、具体的には、上記ルールは、第２のブロックが実行された後からアプリケーションの終了までに、第３のブロックが実行されないことを禁止してもよい。また、第３のブロックは、第２のブロックの実行により変化した環境を第２のブロックの実行前の環境に戻すためのブロックであってもよい。

また、ルールは、アクチュエータ２２及び加熱器２３の少なくとも１つを耐久温度に到達させないために上記所定の２以上のブロックが組み合わせて実行されることを担保するためのルールであってもよい。

これによれば、アプリケーションが実行されたときにアクチュエータ２２及び／又は加熱器２３が耐久温度に到達することを抑制することができ、アプリケーションで制御される装置２０の安全性を向上させることができる。

また、制御対象機器である装置２０は、内部空間を有する筐体２１を備え、ルールは、その内部空間を耐久温度に到達させないために上記所定の２以上のブロックが組み合わせて実行されることを担保するためのルールであってもよい。

これによれば、アプリケーションが実行されたときに筐体２１の内部空間が耐久温度に到達することを抑制することができ、アプリケーションで制御される装置２０の安全性を向上させることができる。

また、上記（ｃ）では、生成されるアプリケーションが、制御対象機器専用のアプリケーションか、その制御対象機器と、その制御対象機器以外の機器とに適用される汎用のアプリケーションかを判定し、所定の２以上のブロックの１つが実行される場合にその所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止する複数のルール候補のうちの、そのアプリケーションの判定結果に応じたルール候補を、ルールとして参照してもよい。

これによれば、専用のアプリケーションと汎用のアプリケーションのように、アプリケーションのバリエーションを増やすことができる。さらに、それらのバリエーションに適したルールが参照されるため、それらのバリエーションのそれぞれで、そのバリエーションのアプリケーションを適切に変更することができる。

また、本実施の形態における情報処理方法は、開発ツール５０のようなコンピュータシステムによって実行される情報処理方法であって、エラーを提示してもよい。つまり、情報処理方法は、（ａ）制御対象機器である装置２０に備えられているアクチュエータ２２及び加熱器２３の少なくとも１つを駆動するためのＮ個（Ｎは２以上の整数）のブロックから、操作者による入力操作に応じて、Ｍ個（Ｍは２以上かつＮ以下の整数）のブロックのそれぞれを選択ブロックとして選択し、（ｂ）少なくともそのＭ個の選択ブロックのそれぞれが実行される順番を、操作者による入力操作に応じて設定することで、少なくともそのＭ個の選択ブロックを含むアプリケーションを生成し、（ｃ）所定の２以上のブロックの１つが実行される場合にその所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止するルールを参照して、アプリケーションに含まれるＭ個の選択ブロックがそのルールに該当する場合には、操作者に対してエラーを提示し、（ｄ）そのエラーの提示を受けた操作者による入力操作に応じて、アプリケーションを変更し、（ｅ）その変更したアプリケーションを出力する。

これによれば、アプリケーション開発者である操作者が、単独での実行が許容されないブロックを単独で実行するように、アプリケーションを誤って生成した場合には、エラーが提示されるため、装置２０を安全に制御することができないアプリケーションが生成されることを抑制することができる。つまり、上述のようにアプリケーションが自動的に変更される場合と同様の効果を奏することができる。

また、上記（ｃ）では、さらに、エラーに対する複数の対処法を提示し、上記（ｄ）では、そのエラーおよび複数の対処法の提示を受けた操作者による入力操作に応じて、Ｍ個の選択ブロックのそれぞれが実行される順番を変更することでアプリケーションを変更してもよい。つまり、本実施の形態における情報処理方法は、開発ツール５０のようなコンピュータシステムによって実行される情報処理方法であって、エラーを提示すると同時に複数の対処法を提示しても良い。

これによれば、エラー提示を確認した操作者が、アプリケーションを変更する手間を低減することが出来る。

また、その複数の対処法は、Ｍ個の選択ブロックに新たなブロックを追加する第１の対処法と、Ｍ個の選択ブロックの順番を変更する第２の対処法と、Ｍ個の選択ブロックのうちいずれかのブロックを削除する第３の対処法とのうちの少なくとも２つを含んでもよい。

これにより、操作者は、複数の対処法のうちの何れか１つの対処法にしたがって、エラーを適切に回避しながら、アプリケーションを変更することができる。また、操作者が対処法を選択する際に、操作者がアプリケーションを作成する意図を満たす選択肢（すなわち対処法）を選択することができる。

また、上記（ｃ）では、さらに、複数の対処法のそれぞれが行われた場合における、アクチュエータ２２又は加熱器２３の駆動によって作用される物体への影響、またはそのアプリケーションへの影響を提示してもよい。つまり、本実施の形態における情報処理方法は、開発ツール５０のようなコンピュータシステムによって実行される情報処理方法であって、エラーに対する対処法を提示するとともに、その対処法を実施することによってアプリケーションに及ぼす影響を同時に提示しても良い。

これによれば、操作者が対処法を選択する際に、操作者がアプリケーションを作成する意図に沿って直観的に選択することが出来る。

また、この情報処理方法では、上記（ｄ）の後に、上記（ｃ）および（ｄ）を繰り返し実行し、エラーの提示回数がＫ回（Ｋは２以上の整数）以上の場合に、エラーに対する複数の対処法を操作者に提示してもよい。

これによれば、エラーの提示が繰り返される場合には、複数の対処法が提示されるため、操作者は、Ｍ個の選択ブロックのそれぞれが実行される順番を、それらの対処法にしたがって簡単に変更することができ、安全なアプリケーションをより簡単に生成することができる。

（実施の形態５の変形例）
装置２０のハードウェアがアプリケーションによって安全に動くか否かは、そのハードウェアの環境条件に依存する。したがって、そのアプリケーションのルールは、最も厳しい環境条件に合わせて決定されるべきである。そのため、ある環境条件では、ハードウェアの機能を最大限に活かすことができない可能性がある。

そこで、本変形例における開発ツール５０は、アプリ制作者がデバイス製造者である場合には、そのアプリ制作者が製造した装置２０に用いられるアプリケーションの開発および制作を、ルールを利用せずに行う。その理由は、アプリ制作者であれば、そのアプリ制作者によって製造された装置２０を安全に動かすための環境条件を理解しているからである。なお、アプリ制作者は、アプリケーションの開発または制作を行う者、団体、または企業であって、アプリケーションの開発者とも呼ばれる。また、デバイス製造者は、装置２０などの機器の製作または製造を行う者、団体、または企業であって、装置２０の製作者または製造業者とも呼ばれる。

つまり、本変形例における開発ツール５０は、アプリ制作者とデバイス製造者とが異なる場合には、ルールを利用したアプリケーションの開発を行い、アプリ制作者とデバイス製造者とが同じ場合には、ルールを利用せずに、アプリケーションの開発を行う。

より具体的には、実施の形態５では、上述のように、アプリケーションが開発または制作される段階で、そのアプリケーションがルールにしたがって変更される。本変形例では、この段階でも、実施の形態３のように、アプリ制作者とデバイス製造者とが同一である場合には、アプリケーションの変更をスキップする。

図３３は、本変形例における開発ツール５０の処理動作を示すフローチャートである。

（ステップＳ５１）
まず、開発ツール５０は、機能ブロックの配置処理およびパラメータ設定処理を行うことによって、アプリケーションを生成する。つまり、開発ツール５０は、制御対象機器である装置２０に備えられているアクチュエータ及び加熱器の少なくとも１つを駆動するための１以上の機能ブロックを含むアプリケーションを生成する。例えば、開発ツール５０は、このステップＳ５１において、図２３のステップＳ２１～２３の処理を実行する。

その後、開発ツール５０は、実施の形態３と同様に、ステップＳ２１６１Ｂ、Ｓ２１６３Ｂ、Ｓ２１６４Ｂ、Ｓ２１６５、Ｓ２１６６およびＳ２１６７を実行する。具体的には、開発ツール５０は、以下のように動作する。

（ステップＳ２１６１Ｂ）
開発ツール５０は、アプリ制作者情報を取得することによって、アプリケーションの制作者（すなわちアプリ制作者）を特定する。

（ステップＳ２１６３Ｂ）
開発ツール５０は、デバイス製造者情報を取得することによって、制御対象機器である装置２０の製造者（すなわちデバイス製造者）を特定する。

（ステップＳ２１６４Ｂ）
開発ツール５０は、アプリ制作者とデバイス製造者とが異なるか否かを判定する。言い換えれば、開発ツール５０は、アプリケーションの制作者と、上述の制御対象機器の製造者とが一致しているか否かを判定する。

（ステップＳ２１６５）
開発ツール５０は、アプリ制作者とデバイス製造者とが一致していない場合には（ステップＳ２１６４ＢのＹｅｓ）、アプリケーションに含まれる１以上のブロックに関するルールを取得する。

（ステップＳ２１６６）
開発ツール５０は、アプリケーションに含まれる１以上の機能ブロックがルールに該当するか否かを判定する。

（ステップＳ２１６７）
開発ツール５０は、それらの１以上の機能ブロックがルールに該当すると判定すると（ステップＳ２１６６のＹｅｓ）、そのルールにしたがってアプリケーションを変更する。

（ステップＳ５２）
開発ツール５０は、アプリ制作者とデバイス製造者とが一致している場合には（ステップＳ２１６４ＢのＮｏ）、アプリケーションに情報を付加する付加処理を行う。付加処理では、開発ツール５０は、第１付加情報と、第２付加情報および第３付加情報のうちの少なくとも一方の情報とを、アプリケーションに付加する。第１付加情報は、そのアプリケーションにルールが適用されていないことを示す情報である。第２付加情報は、そのアプリケーションが生成された時期を示す情報である。例えば、第２付加情報は、アプリケーションが生成された日付を示す。その日付は、以下、アプリ作成日とも呼ばれる。また、第３付加情報は、アプリ制作者が機器の製造者である場合に、その製造者を識別するための製造者識別情報である。

（ステップＳ５３）
開発ツール５０は、ステップＳ２１６７の処理の後には、変更されたアプリケーションを出力する。一方、開発ツール５０は、ステップＳ５２の処理の後には、付加処理済みのアプリケーションを出力する。つまり、開発ツール５０は、アプリ制作者とデバイス製造者とが一致している場合には（ステップＳ２１６４ＢのＮｏ）、ルールをアプリケーションに適用することなく、情報が付加されたアプリケーションを出力する。

このように、本変形例における情報処理方法は、開発ツール５０のようなコンピュータシステムによって実行される情報処理方法である。そして、この情報処理方法では、制御対象機器に備えられているアクチュエータ及び加熱器の少なくとも１つを駆動するための１以上のブロックを含むアプリケーションを生成し、そのアプリケーションの制作者を特定し、その制御対象機器の製造者を特定し、そのアプリケーションの制作者と、その制御対象機器の製造者とが一致しているか否かを判定し、（ａ）アプリケーションの制作者と、制御対象機器の製造者とが一致していない場合には、そのアプリケーションに含まれる１以上のブロックに関するルールを取得し、そのルールにしたがってアプリケーションを変更し、変更されたアプリケーションを出力し、（ｂ）アプリケーションの制作者と、制御対象機器の製造者とが一致している場合には、ルールをアプリケーションに適用することなくそのアプリケーションを出力する。

したがって、本変形例では、アプリ制作者とデバイス製造者とが異なる場合には、アプリケーションへのルールの適用によって、そのアプリケーションが変更されるため、実施の形態５と同様の効果を実現することができる。さらに、アプリ制作者とデバイス製造者とが同じ場合には、実施の形態３と同様に、ルールの適用とアプリケーションの変更が省かれるため、処理負荷の軽減を図ることができる。さらに、その場合には、ルールが適用されていないアプリケーションによって、制御対象機器である装置２０のハードウェアが動作するため、そのハードウェアの機能を有効に活用することができる。

また、本変形例における情報処理方法の上述の（ｂ）では、さらに、第１付加情報と、第２付加情報および第３付加情報のうちの少なくとも一方の情報とを、そのアプリケーションに付加する付加処理を行う。そのアプリケーションの出力では、付加処理済みのアプリケーションを出力する。ここで、第１付加情報は、アプリケーションにルールが適用されていないことを示す情報であり、第２付加情報は、そのアプリケーションが生成された時期を示す情報である。また、第３付加情報は、そのアプリケーションの制作者が機器の製造者である場合に、その製造者を識別するための情報である。

したがって、本変形例では、アプリケーションにルールが適用されていない場合には、制御対象機器である装置２０のデバイス３００は、情報が付加されたアプリケーションを取得する。

例えば、アプリケーションに第１付加情報および第２付加情報が付加されている場合、デバイス３００は、その第１付加情報がアプリケーションに付加されているため、そのアプリケーションに対してルールを適用するか否かを判定することができる。具体的には、デバイス３００は、そのアプリケーションに付加されている第２付加情報に基づいて、ルールの適用の判定を適切に行うことができる。例えば、デバイス３００は、ルールの更新日を特定し、その更新日が、第２付加情報によって示されるアプリ作成日以前であれば、アプリケーションに対してルールを適用しないと判定することができる。その結果、デバイス３００は、ルールの適用とアプリケーションの変更とを省くことができる。つまり、開発ツール５０と同様に、デバイス３００でも、処理負荷の軽減を図ることができる。

一方、デバイス３００は、その更新日がアプリ作成日よりも後であれば、アプリケーションに対して更新後のルールを適用すると判定することができる。つまり、生成されたアプリケーションが古い場合に、その古いアプリケーションによって装置２０が動作すると、その装置２０の安全性を担保することが難しい場合がある。しかし、このような場合には、第２付加情報によって、その古いアプリケーションに対してルールが適用されて、アプリケーションが変更される。したがって、装置２０の安全性を容易に担保することができる。

また、例えば、アプリケーションに第１付加情報および第３付加情報が付加されている場合でも、デバイス３００は、その第１付加情報がアプリケーションに付加されているため、そのアプリケーションに対してルールを適用するか否かを判定することができる。具体的には、デバイス３００は、そのアプリケーションに付加されている第３付加情報に基づいて、ルールの適用の判定を適切に行うことができる。例えば、デバイス３００は、そのデバイス３００を含む装置２０の製造者が、第３付加情報である製造者識別情報によって識別される製造者と一致するか否かを判別する。そして、デバイス３００は、それらの製造者が一致すると判別すると、アプリケーションに対してルールを適用しないと判定することができる。その結果、デバイス３００は、ルールの適用とアプリケーションの変更とを省くことができる。つまり、開発ツール５０と同様に、デバイス３００でも、処理負荷の軽減を図ることができる。

一方、デバイス３００は、それらの製造者が一致しないと判別すると、アプリケーションに対してルールを適用すると判定することができる。例えば、生成されたアプリケーションは、アプリ制作者によって製造された制御対象機器である装置２０だけでなく、他のデバイス製造者によって製造された装置２０にも用いられる場合がある。他のデバイス製造者によって製造された装置２０が、そのアプリケーションによって動作すると、その装置２０の安全性を担保することが難しい場合がある。しかし、このような場合には、第３付加情報によって、そのアプリケーションに対してルールが適用されて、アプリケーションが変更される。したがって、他のデバイス製造者によって製造された装置２０の安全性を容易に担保することができる。

なお、上述の例では、デバイス３００が、アプリケーションに付加されている情報に基づいて、ルールの適用およびアプリケーションの変更を行う。しかし、実施の形態１～４と同様に、デバイス３００の代わりにデバイスマネージャ２００などが、アプリケーションに付加されている情報に基づくルールの適用およびアプリケーションの変更を行ってもよい。

（他の実施の形態）
以上、本開示の１つまたは複数の態様に係るシステムについて、実施の形態に基づいて説明したが、本開示は、この実施の形態に限定されるものではない。本開示の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本開示の１つまたは複数の態様の範囲内に含まれてもよい。

また、上記各実施の形態において、シーケンスマネージャ１００及びデバイスマネージャ２００は、クラウドサーバ１０に含まれていたが、これに限定されない。シーケンスマネージャ１００及び／又はデバイスマネージャ２００は、装置２０に含まれてもよい。また、ＵＩ４００は、端末３０に含まれていたが、装置２０に含まれてもよい。

また、上記各実施の形態において、劣化情報に基づいて、アプリケーションが変更されてもよい。例えば、デバイス３００は、複数の劣化レベルと複数のパラメータの変換方法とが対応付けられたパラメータ変換情報を参照して、劣化レベルに対応する変換方法を取得し、取得した変換方法を用いてブロックに含まれるパラメータを変換してもよい。変換方法としては、例えば、変換後の値で定義されてもよいし、変換前の値に適用される係数で定義されてもよい。

また、上記各実施の形態では、実行前確認においてアプリケーションを変更し、その後アプリケーションが実行されていたが、これに限ったものではない。例えば、デバイス３００の状態が想定と異なっていたときは、アプリケーションを変更せず、デバイスマネージャ２００及び／又はシーケンスマネージャ１００に実行中止（エラー）が通知されてもよい。

複数の機能ブロックで規定されたアプリケーションを実行することができる家庭用電化製品、およびそのアプリケーションを生成する装置等に利用できる。

１ システム
２ａ、２ｂ、２ｃ、２ｄ 施設
１０ クラウドサーバ
１１ プロセッサ
１２ メモリ
２０、２０ａ、２０ｂ、２０ｃ、２０ｄ、２０ｅ、２０ｆ、２０ｇ、２０ｈ 装置
２１ 筐体
２２ アクチュエータ
２３ 加熱器
２４ 制御部
３０、３０ａ、３０ｂ、３０ｃ、３０ｄ 端末
３１ ディスプレイ
３２ 入力デバイス
４１ ブロックデータベース
４２、１３００ ルールデータベース
５０ 開発ツール
５１ プロセッサ
５２ メモリ
５３ ディスプレイ
５４ 入力部
６０ アプリ提供サーバ
１００ シーケンスマネージャ
２００ デバイスマネージャ
３００、３００ａ、３００ｂ、３００ｃ、３００ｄ、３００ｅ、３００ｆ、３００ｇ、３００ｈ デバイス
４００、４００ａ、４００ｂ、４００ｃ、４００ｄ ＵＩ
１０００、１２０１ ブロック
１００１、１００２、１００３、１００４、１００５、１００６ パラメータ
１１００ デバイスデータベース
１１０１ デバイス情報
１２００ 実行内容宣言
１２０２ デバイスに関する情報
１２０３ 順番の情報
１３０１、１３０２ ルール
２０００ 情報処理システム
Ｃ１～Ｃ５ 対処法
Ｄ１ パラメータ設定領域
Ｄ２ ブロック一覧領域
Ｄ３ 対象装置領域
Ｄ４ 選択ブロック領域
Ｅ１、Ｅ２ エラーメッセージ
Ｆ１００ 準備フェーズ
Ｆ２００ アプリ実行前フェーズ
Ｆ３００ アプリ実行フェーズ
Ｒ１１～Ｒ１３、Ｒ２１～Ｒ２３、Ｒ３１～Ｒ３３、Ｒ４１～Ｒ４３ 専用ルール
Ｒ１００、Ｒ２００、Ｒ３００、Ｒ４００ 汎用ルール

Claims (7)

1. コンピュータシステムによって実行される情報処理方法であって、
   （ａ）制御対象機器に備えられているアクチュエータ及び加熱器の少なくとも１つを駆動するためのＭ個（Ｍは１以上の整数）のブロックのそれぞれが実行される順番を、操作者による入力操作に応じて設定することで、前記Ｍ個のブロックを含むアプリケーションを生成し、
   （ｂ）所定の２以上のブロックの１つが実行される場合に前記所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止するルールを参照して、前記アプリケーションに含まれる前記Ｍ個のブロックが前記ルールに該当する場合、前記操作者に対してエラーを提示し、
   さらに、前記エラーに対する少なくとも１つの対処法と、
   前記対処法が行われた場合における、前記アクチュエータ又は前記加熱器の駆動によって作用される物体への影響、または前記アプリケーションへの影響を提示する、
   情報処理方法。
2. 前記情報処理方法では、さらに、
   （ｃ）前記エラーの提示を受けた前記操作者による入力操作に応じて、前記アプリケーションを変更する、
   請求項１に記載の情報処理方法。
3. 前記（ｂ）では、さらに、
   前記所定の２以上のブロックの残りの少なくとも１つを、前記エラーに対する対処法として提示する、
   請求項１に記載の情報処理方法。
4. 前記（ａ）において、前記Ｍ個のブロックのうちの１つのブロックの順番が前記操作者による前記入力操作に応じて設定されるごとに、前記（ｂ）の処理を行う、
   請求項１に記載の情報処理方法。
5. 前記（ｂ）では、さらに、前記エラーに対する複数の対処法として、
   前記Ｍ個のブロックに新たなブロックを追加する第１の対処法と、
   前記Ｍ個のブロックの順番を変更する第２の対処法と、
   前記Ｍ個のブロックのうちいずれかのブロックを削除する第３の対処法とのうちの少なくとも２つを提示する、
   請求項１に記載の情報処理方法。
6. 前記（ｂ）では、さらに、前記エラーに対する対処法として、
   前記Ｍ個のブロックの順番を変更することと、前記Ｍ個のブロックのうちいずれかのブロックを削除することのいずれかを提示する、
   請求項１に記載の情報処理方法。
7. プロセッサと、
   前記プロセッサに接続されたメモリとを備え、
   前記プロセッサは、前記メモリを用いて、
   （ａ）制御対象機器に備えられているアクチュエータ及び加熱器の少なくとも１つを駆動するためのＭ個（Ｍは１以上の整数）のブロックのそれぞれが実行される順番を、操作者による入力操作に応じて設定することで、前記Ｍ個のブロックを含むアプリケーションを生成し、
   （ｂ）所定の２以上のブロックの１つが実行される場合に前記所定の２以上のブロックの残りの少なくとも１つが実行されないことを禁止するルールを参照して、前記アプリケーションに含まれる前記Ｍ個のブロックが前記ルールに該当する場合、前記操作者に対してエラーを提示し、
   さらに、前記エラーに対する少なくとも１つの対処法と、
   前記対処法が行われた場合における、前記アクチュエータ又は前記加熱器の駆動によって作用される物体への影響、または前記アプリケーションへの影響を提示する、
   情報処理装置。