こうえいフォーラム第 12 号 / 2004. 1

DVCfai（Φ）
を用いたFA開発アーキテクチャ
NEW ARCHITECTURE FOR DEVELOPMENT OF FACTORY AUTOMATION (FA) SYSTEMS USING
DVCfai(Φ)

石田哲史*・藤澤宏*

Tetsushi ISHIDA and Hiroshi FUJISAWA

With the spread of multimedia information and evolution of broadband data transfer, FA systems must go
beyond conventional DI/O control using PLC and must incorporate advanced supervision and control
systems that utilize new technology such as FL-net, Device-net and visual supervision.
DVCfai(Φ) consists of a group of network-linked modules and can combine the optimal module for eachdevelopment requirement. In program development, the system utilizes STM to enable software to be
developed independently of hardware.
Key Words：DVCfai(Φ), hardware-independence, FA, PLC, FL-net, Devicenet, STM

1. FA市場の概況
近年のFA機器市場では、不況とデフレの煽りを受けて各企業とも業績の下方修正を強いられ、設備投資の大幅な削減がなされているが、その一方で設備の老朽化やリストラによる要員削減を補填するための設備自動化、段取り替え作業の簡略化を図る新しい製造ラインの構築、高機能ロボットの導入などが暫時進められている。
一方、エンドユーザからは費用対効果を最大限にするため、高機能化・短納期・高信頼（メンテナンスフリー）という要求仕様を突きつけられ、要求に対する十分な性能を確保できないなどといった課題を数多く抱えている。
情報機器はムーアの法則に従って常に進化をし続けており、新技術出現のたびにそれまで障壁となっていた数々の技術的課題を容易に解決できるようになってきている。
現在、FA機器の世界においても製品競争力を確保するため、積極的に新技術を採用せざるを得ない状況にあるにもかかわらず、機器メーカ間の開発の足並みがまったく揃わず、機器ごとに特化したプログラム記述が多くなっている。

制御回路開発などの特徴を持つ機器として定着しているが、最近では高性能な通信能力や豊富なツール群を持つPC（パソコン）と組み合わせたFA機器も市場を賑せるようになってきている。
技術の高度化に伴い、PLCの得意とするDI/O・AD・DAを中心とした入出力制御機能だけでは顧客満足を満たせず、HMI（ヒューマンインターフェイス）を中心とした監視・操作性の向上、複数のFA機器をネットワークで結んだ高度な連係制御機能、パソコンを中心とした情報処理機器との連係などが要求されるようになったためである。
これら新技術はリレー制御を元にしたPLCの基本コンセプトとはまったく異なるため、汎用PLCにこれらの機能を搭載することは極めて難しく、各メーカともハードウエアに性能改良を加えながら、メーカごとに新技術へ対応している。
その結果、PLCの標準性が奪われ、新技術（特殊ユニット・拡張基板）を利用する方策として、PLCメーカが各社固有のラダープログラミングを採用するようになっていったた
め、開発者はメーカ固有のプログラミング手法を習得したり、

2. FA機器開発における課題（1）開発環境の課題
FA機器開発に関して最も標準的な構成部品はPLC（シーケンサ）になる。

開発環境の再整備を強いられるようになっていった（図−1）。
また、ラダープログラムの標準性が奪われることにより、過去の知的資産を流用し難い状況も同時に生み出している。
こうした変遷の中で開発者は次第にPLCをPCの拡張基板の一部として捉えるようになり、情報処理の中心をPCに移PLCはハードウエアの持つ信頼性、リレー回路設計をベ行し始めている。これにより開発作業はラダープログラムースとした開発手法（ラダープログラミング）による容易な以外のプログラミング技法（VC・VB・JAVA）やWindows開発技術、データベース開発技術を習得し、開発環境を整備*

日本工営パワー・システムズ（株） システムソリューション部

することが強いられるようになった。
49

DVCfai（Φ）
を用いたFA開発アーキテクチャ

語間のインターフェイスをとるためのコードなど主機能には関係のない部分の開発も無視できない作業量となってきている。
一方、試験フェーズにおいては、増大するステップ数によって膨大な確認項目数となっている。試験においては多くの装置と連係するケースが多いことから、試験条件において入力タイミングを厳密に管理するなどの試験手順や試験環境構築が複雑となってきており、現在の開発環境下における生産は限界に近づいてきていると言える。
表−1は電力監視・制御装置における試験時の課題をユーザ（電力会社）と装置開発メーカの双方にてアンケートを採った結果である。この結果からも生産環境における限界が読みとれる。

図−1

ユーザーと技術者の悩み（3）信頼性の低下
PLCはFA現場において、ミッションクリティカルな機能を司ることが多く、高信頼性が絶対条件となる。

（2）機能追加による開発量の増大

FA機器の情報処理の中心がPLCからPCに移行するにつ

FA機器の高機能化に伴い、構成するPLC数やIO点数の増れ、システム全体の信頼性がPCの影響を受けることが多く大、パソコン計装など監視制御機能の拡充に比例して開発なってきた。PCは汎用機器であるため、ハードウエアプラ

コード（ステップ数）が増大している。

ットホーム・OSともに幅広い機能において拡張性が確保さ

さらに、開発コードはラダー言語・SFC言語・VC・VB・JAVAなど多様な言語からシステムが構成されるため、機能追加によるステップ数の増加や、各プログラミング言れている。その反面、マルチベンダ環境においては信頼性を保証することが難しい状況にある。
また、PCはDISKやFANなどの回転部品が多く、信頼性確保のためにはクラスタ技術など高価で複雑な構成が必要

表−１

電力環視・制御装置の試験における課題となる。
一方、FA現場は環境条件の厳しい大型機械加工場から空調の整った精密加工場まで利用される環境は幅広く、耐環境性に優れ、安定した動作が保証されるPLC技術が必要不可欠な状況にある。
（4）要員確保と教育の課題
開発手法（言語や方法論）やハードウエアの技術進化により、多様な開発方法が選択できるようになっている。
これらの技術を幅広く習得し、活用するためには相応の知識と経験を必要とするため、実際の作業においては開発言語やプラットホーム別に担当を分けているケースが多いが、昨今では短納期・低コスト化・リストラなどにより、開発に必要な要員を確保することも難しくなってきている。
さらに、短納期や技術革新の早さも加わり、要員教育においても十分な研修期間や実地経験を積ませることが難しく、その結果、人的ミスによる不具合増加を助長している状況に陥っている。
（5）知的資産活用とソリューション技術向上の課題
技術革新により生産性の改善は進んではいるものの、ソ50

こうえいフォーラム第 12 号 / 2004. 1

フトウエアやハードウエア技術の変遷が激しいため、過去特化し、オブジェクト指向開発におけるビヘービアモデルに開発したプログラムなど知的資産を活用するためには最と同一の概念を持つなど次世代に適用しやすい手法と考え、新環境に合わせた改良が必要となり、流用開発においては状態遷移表設計手法を採用した。

移植作業量が多くなっている。
また、上記（4）項による状況から、新しい開発手法（言語（2）CASEツールによるクリーンルーム開発

や方法論）を実践の場において習得することが多く、開発のクリーンルーム開発はオブジェクト指向デザインパター道具であるはずの手法の習得に追われ、本来開発者が実施ン開発に代表される。特にUMLを用いたCASEツールはパしなければならない監視のための知的センシング技術や高ターンジェネレータを具備することにより、モデル作成段度な連係制御技術などの技術向上が進んでいない。

階からモデルに適合しない設計を排除する方法を採っている。さらに、最近ではモデル検証を実施しながらのスパイ（6）メンテナンス性の課題ラル開発によって短納期も可能としている。

PLCとPCが混在するシステム構成により、製品のライフ一方、FA機器開発においてはラダー用ツールを代表としサイクルが短いPC部品の確保やOSも含めたソフトウエアのてツール類がビジュアル化され、十分な操作性を備えてい構成管理が複雑化している。

るが、ラダー開発では設計の検証が試験実施後に判明する

また、開発言語の多様化や開発ステップ数の増大に伴い、ため、試験結果に課題があった際の設計への手戻りが大きプログラムメンテナンス時のトレースアビリティが低下しい。そのため、設計ツールは設計検証も含めたツールが望ている。

ましく、プロトタイプ開発手法やスパイラル開発手法が容易な、プログラム完全自動生成型のCASE環境が望ましい。

3. FA開発方法論の見直し（3）ハードウエアオリエンテッドの設計からソフトウエア（1）状態遷移表設計手法の適用
PLCを用いたFA機器においては定周期にプログラムが繰り返し実行されるシーケンシャル制御を行っている。

オリエンテッドの設計への変更
FA機器開発は従来、プログラムというよりは電気設計に

PLC用ラダープログラムはシーケンシャル制御を前提に近い設計技術が必要であり、PLCについても同様の開発方したプログラム手法で、はしご段に記載された処理を先頭法を踏襲し、ハードウエアユニット（DI/O、AD、DA）の処からはしご段を降りるように順次実行し、処理が終了次第、理を対象としていた。そのためハードウエアをどう操作し、再び先頭に戻るどう利用できるかが重要となり、ラダープログラム等の繰り返し実行方式となっている。

処理ステップ数が大きくなると各処理の起動時間や装置間での通信タイミングが変化し、設計や試験が難しいうえ、PLC用言語は言語機能拡張においてハード依存を強めることで記述の簡略化を追求した。

処理中に参照するメモリ状態が変化してしまい、シーケンその結果、PLCプログラムは機種依存性が強くなり移植

シャル処理中のメモリ参照において、処理タイミングによ性が失われた。また、プログラムの巨大化に伴い、ハードり実行結果が異なってしまうといった課題がある。

ウエアを意識したプログラムではアセンブラと同様、生産こうしたことから、設計時にタイミングが明確となる設性が期待できないなどの課題もある。

計手法が望まれるようになってきている。タイミング設計

従来のPLCを用いた装置は、運用期間5〜10年程度が一般においてはモデル記述型手法としてアローダイアグラムや的であったため、移植性を考慮することはそれほど重要でシーケンス図・状態遷移図などの方法があるが、処理タイはなかった。しかし最近ではコスト・信頼性・メンテナンミングの抽出や処理の漏れ抜けを精査することが難しい。

ス性においてソフトウエアの資産化が重要な製品戦略とな

また、条件記述型手法として、フローチャート・HCPチってきており、デザインパターン開発手法（ソフトウエアのャートや状態遷移表設計手法などがあげられるが、最も処部品化）もFA機器開発で注目されつつあり、IEC61499-1で理タイミングが扱いやすい手法として状態遷移表を用いたFBを用いた定義化も進められている。

設計が考えられる。
近年IEC61131-3で標準化された設計手法がFA開発においては主流となっているが、FAのみを対象としているため、以上によりソフトウエアの独立性を高めインディペンデント・プラットホームな開発環境は、巨大化するFAプログラミングの世界でも必須と考える。

汎用ソフトウエアとの親和性が低く、オブジェクト指向設計などの生産性の高い設計手法への移行が難しい。

（4）自律型ネットワークによる機能の能動構成

一方、状態遷移表はFAという機器に特化するのではなく、情報処理技術においては、CORBA・DCOM・JINIなどに代リアルタイム性というプログラムの動作条件・機能目的に表されるとおり、機能をネットワークで能動的に接続し、51

DVCfai（Φ）
を用いたFA開発アーキテクチャ

各機能がソフトウエアの要請に対してサービスを提供する

4. DVC faiのフュージョン・アーキテクチャ

分散コンピューティングが脚光を浴びている。

（1）クリーンルーム開発を可能とする、 FA開発用−CASE

これは企業内基幹系システムにおいて、巨大サーバが処理（サービス）の全てを提供することの限界から、より身軽なシステムへの移行が始まり、シン・クライアントを含む3層構成によるクライアント／サーバ方式が主流となってきたことからも明らかである。オブジェクトベースの分散コンピューティングは機器の処理能力を有効に活用し、メンテナンス性・信頼性・セキュリティ面で有効な手法であることが数々の導入事例で立証されてきている。
このことから、FA機器においてもネットワークベースで機能を再構成できる具体的な手法が必要である。

TOOL ZIPC FOR DVC
DVCではFA機器の将来を考慮し設計手法に状態遷移表を採用することで、設計時における状態遷移表記述、状態遷移表設計からのプログラムコード作成、検証時における状態遷移制御処理確認などについて、組込み開発用CASEツールである

ZIPCをベースにCASE化を実現した注1）。

さらに、状態遷移表に記述する処理（プログラム）に関しては機器（リレー）を制御する制御仕様の記述を可能とし、制御仕様記述言語（特願2001-302608）をもとにプログラムコードの自動生成を実現した。
これにより全てのプログラムコードを仕様記述（モデル）（5）資産活用を考慮した設計の階層化から自動生成することでクリーンルーム開発を可能とした。

ナレッジマネジメント（KM）は数年前より各企業で取り組む重要な企業戦略となっている。

図−2にCASEツールでの作成例を示す。
また、制御仕様記述言語で記述した制御仕様は、C言語

ソフトウエアについても知的資産化を重要戦略としている企業が多いが、ソフトウエア内には知的資産部分（他の開ソースとしてコード生成されるため、DVCアーキテクチャ以外のシステム環境への移植も容易となった。

発でも流用可能な部分）と機種や機器に依存した部分が共存することが多かったため、資産管理が行いにくかった。
しかしながら、デザインパターン開発においてはインディペンデント・プラットホームを指向しているために、デザインパターンは他への流用が可能な資産として期待が掛かっている。
また、デザインパターンはパターンジェネレータと併用することにより、デザインパターン設計とプログラムコードが完全一致するため、デザインパターンのみの管理でプログラム管理も可能となる。
このような設計レベルの階層化によって資産活用可能な知識部分のみ管理していくことが今後の知識管理上重要で
図−2ある。

図−3 システムアーキテクチャ

52

制御仕様記述設計こうえいフォーラム第 12 号 / 2004. 1（2）ソフトウエアの独立性を高めるネットワークベースの多彩なシステム構築を可能とするゲートウエイ機能を具備。
（対象ネットワーク：Ethernet、FL-net、Device-net）

アーキテクチャ DVC‐WARE
図−3の通りDVCのアーキテクチャはネットワークをベースとしている。DVC-WareがOSやハードウエアの違いに（4）CASEと設計データベースを連動した資産活用機能

よる機種依存からソフトウエアの独立性を確保し、FL-net

DVC開発はZIPCを利用したビジュアルな開発環境を提供（OPCN-2）注2）の持つネットワーク再構成機能が、システムする。さらにZIPCに登録した状態遷移表と制御仕様記述か動作中の再構成を可能としている。

ら生成したプログラムコードは、再利用とプロトタイプ開

さらに、プラットホームに依存しないDVCアーキテクチ
ャによって、設計仕様からプログラムコードを自動生成す発を効果的に実現するため、設計データを全てDBに保管する機能を設けた。

る際に、ターゲット環境を指定するだけでWindows上で動DBに保管することで、過去の類似設計の参照や再利用部作するコードが生成され、設計仕様や生成されたコードに品の検索、メンテナンス対象部品の検索などの支援を可能

手を加えることなく動作可能となる。とし、設計情報と知的資産管理の連係を可能とした。

（3）ブロードバンド時代に対応した機能（5）μITRONベースのマイコン開発環境の採用

ブロードバンド時代の到来によって通信性能が飛躍的に

DVC-Wareを動作させるプラットホームには国産OSのμ向上してきている。DVCはブロードバンドを十分に生かすITRONを採用し、国内のITRONベースプログラムの活用を機能とハードユニットを装備し、付加価値の高いシステム可能とした。
また、DVCアーキテクチャによって設計され、自動生成の構築基盤を提供する（図−7）。
以下にネットワークに対応した機能について述べる。

されたソースコードはμITRON上で動作可能なコードであ・DVC内にDBクライアント機能を具備し、SQL注3）言語ることから、DVC以外のITRONベースの機器への移植も容易とした。

を利用した制御機構の開発が可能。
・広い通信帯域を利用し、画像ストリーミング機能や画DVCはμITRONのインターフェースを提供しており注5）、DVCアーキテクチャによる自動生成コード以外にユーザが像解析用データ生成機能を具備。
・ブラウザからの装置運転状態監視や、装置異常時にお作成した高度な機能をDVCに組み込むことが可能である。

けるEメール通報機能など、モバイルやインターネッ

ユーザの開発した高度な機能は、デバッガ注6）を利用するこトを活用したFA装置の開発が可能注4）。とで、マイコン基板同様の開発および試験を実施可能とした。

・複数のフィールドネットワークと連係することにより

図−4 冗長構成機構
53

DVCfai（Φ）
を用いたFA開発アーキテクチャ

図−53階層アーキテクチャ（6）信頼性の高いハードウエア構成
1）PLC同等のハードウエアの信頼性
FANレス・空調レス・DISKレスを実現し、電源規格に「電気協同研究48-3、電力規格B-402」に対応可能な電力制御用特殊電源を具備した。
2）ユニットのインテリジェント化による自律分散の実現
各ユニットはそれぞれがCPUを搭載することで分散処理を、また冗長に必要なユニットを増設するだけで冗長構成を可能とした（特願2002-49873）。
冗長機能は図−4に示す通り、FL-netと構成制御信号によって、論理部のみならずIO入出力までの冗長を可能とし、2重化やN重化を自由に構成可能とした。
なお、冗長機能によってノンストップでプログラム変更・ハードウエア点検・装置交換を可能とした。
（7）JAVAを用いたSCADA開発ツール
DVCはEthernet上にあるWindowsサーバとソケット通信を行う機能を持ち、Windowsサーバ上にツールを組み込むこと

図−6

ＪＡＶＡによる設備監視画面表示

5. 効果
現在、効果についてのデータを採取中であるが、現時点において以下の結果を得ている。

でリアルタイムにグラフィカル表示するSCADA機能を具備する。さらに、WindowsサーバにDBを構築することによりEJBに対応したソリューションの構築も可能とした（図−5）。
リアルタイム監視はJAVAソケット通信によってサーバ（サーバ側JAVA）からクライアント（クライアントアプレット）へ情報更新トリガを与えることで、情報更新のリアルタイム化を実現した。
また、ブラウザに表示する画面は画面表示内容をデータ化することで、JAVAアプレットがデータを読み込んで画面制御を行う方式とし、画面データはCADデータ（DXF）を直接JAVAアプレットが処理することで、CADによる画面作成を可能とした（図−6）。

（1）DVCアーキテクチャの生産性
1）制御仕様記述言語の生産性
DI/Oを中心とする制御処理をC言語で作成した場合、処理に必要なメモリの割り付け作業、接点入出力のためのドライバーIO処理記述などハードウエアとソフトウエア構成を意識した開発を必要とする。
しかしながら、制御仕様記述言語は、ラダー記述と同様の論理構成が日本語で記述でき、メモリ割付・開放・クリアなどのガベージコレクション機能を実装し、メモリの不正操作の防止や記述量の削減を可能とした。
また、メモリ操作が不要となったことにより、C言語記
述と比較してコーディング量が30％〜40％減少し、約1.5倍

54こうえいフォーラム第 12 号 / 2004. 1の生産性向上が得られた。制御仕様記述言語は設計仕様記

また、ZIPCジェネレータで設計コメント付きのC言語ソ述と同様に利用できるため、仕様作成・設計・製作作業をースプログラムを生成するため、記述方法が統一されたソ同時に進行することが可能となった。

ースコードができ、保守時においてトレースアビリティの2）CASEによる設計・製作試験の合理化向上が図れる。

状態遷移表設計により、処理タイミングを意識した動作

2）システム構成
図−7のように各IOユニットをネットワークに接続する設計が可能となった。
また、プログラム生成前に遷移表動作をZIPC上で確認できることから設計ミスを防止することができた。

だけで2重化、3重化を容易に構成できるため、MTBFを向上させることができる。

製作においては、チェッカとジェネレータにてハード資源

また、ネットワークで容易にシステムの再構成が可能とのアサイン違反や制御仕様記述規約違反などを自動検査し、なるため、電源を停止することなく点検の際に予備ユニッ動作可能なプログラムのみ生成するため、ヒューマンエラ

トを接続し、運転を切り替えることでシステム停止を不要

ーによるケアレスミスを設計時点で排除できた。とすることができる。プログラム入れ替え時についても前さらにプログラムの動作試験中は、ZIPCのTAP機能を利用することによってDVC上の遷移状態をZIPCツール画面上に表示させることができ、タイミング試験による遷移表のカバレッジが把握可能となった。

記同様に予備ユニットを用いてノンストップでプログラム交換が可能であるため、メンテナンス性が向上した。
システム構成においては、ネットワークで各ユニットを接続するだけで、さまざまなソリューションに対応した監LANで接続した開発環境においては、ブラウザを使用してFLネットの状態・DI/O・AD・DAの状態をモニタしなが視制御用のハードウエアプラットホームを自由に構築することが可能となる。

ら製作・試験を進めることも可能とした。

6. 課題と将来展望（2）DVCアーキテクチャの信頼性（1）課題

1）プログラム構造

単純なDI/Oユニットもネットワーク機能をベースに動作メモリの設定・クリア、ドライバー連係処理など、シスするため、OSによるプログラム制御が必要となることから、テムに重大な影響を及ぼす処理を完全に隠蔽しているため、OSレスまたは簡易OS程度でプログラムを動作させている

PLCと同様に信頼性の高いプログラムが可能となる。

従来型PLCに比較して接点入出力が遅延する。そのため、

図−7 製品ユニット群とシステム構成
55

DVCfai（Φ）
を用いたFA開発アーキテクチャ各ユニット間で協調した分散処理が実施可能なマルチプロ

参考文献

セッサプログラム動作方式を導入する必要があると考える。

1） 電気学会技術報告2000年5月

プログラム面の課題としては、ラダー言語がモデル型言語であるのに対し、制御仕様記述型言語が記述型言語であるため、視覚的（直感的）な面でのプログラム動作把握が行いにくい面がある。
また、開発環境面としては、ZIPCからCソースを生成し、オブジェクトに変換後ターゲットにダウンロードするという一連の作業時間がPLCに比較し複雑で時間を要している。の動向

近年、組み込みシステムの開発においてはオブジェクト指向設計がより進化したデザインパターン設計に移行しつつあることはすでに述べた。ソフトウエアの部品化は生産

シーケンス制御技術

電気学会2） 電気協同研究1999年1月

第54巻

第4号

ム機能検証試験の効率化と品質管理
3） IEC61131-3

集中制御所システ

電気協同研究会

ハンドブック PLCopenJAPAN4） 日本電機工業会ホームページ
http://www.jema-net.or.jp/Japanese/hyojun/hyojun.htm5） 欠陥ゼロのソフトウエア開発
6） 計測技術2000年6月373号（2）将来展望

第781号

最前線

日経BP

特集：多様なニーズに対応するPLC

日本工業出版

7） オートメーション2001年8月 46号 特集：フィールドネットワ
ーク技術の現状を探る

日刊工業出版プロダクション

8） オートメーション2002年2月 47号 特集：生産・情報システム

性と信頼性の両面から求められている。特にパターンジェ技術の新展開

ネレーターによるコード生成は充実した設計支援環境とな

9） ソフトウエアの未来ってきている。

10）Real-time UML:Developing Efficient Objects for Embedded

デザインパターンはビジネス系（事務処理系）処理では一般化した設計手法となっているが、FA系についてはパター

日刊工業出版プロダクション
FTP編

Systems Bruce Powel Douglass11）Executable UML: A Foundation for Model-Driven

ンをどう作るかが現在研究段階にある。FA設計においてはStephen Mellor , Marc Baler

シーケンス図を多く用いるが、シーケンス図はオブジェク

12）計測と制御2002年2月41号

ト指向設計でも取り入れられ、リアルタイム制御が必要なFA系への適用も準備されている。
しかしながら、FA系はソフトウエア実装がハードウエアごとに異なることからUMLに対応したツールなどの適用が

境堅著

15）ZIPC

NO.21 2001地中線設備情報監視装置の開石田哲史・荒川隆敦・田邊秀治・渡邊與志郎
WATCHERS Vol.6分散制御指向FA開発アーキテクチャ

石田哲史

ト指向のモデル化・抽象化が行いやすいUML手法による設

ZIPCはCats社の商標です。

計が可能と思われる。

Windowsのため、人間系で検討した制御動作タイミングから自動的に遷移表を生成する支援機能により、制御動作に注目したソフトウエア構築への対応なども必要になると考える。
注釈
注1

ZIPCはCats （株）の組み込み開発支援ツールの名称。

注2

FL-netとは日本電機工業会が規格化した、FA向けのネットワークプロトコルである。

注3

select文においては、メモリ資源や通信性能の制約により記述に制限をかけ実装を可能とした。

注4

JAVAを利用したHMI構築については、DVC以外にPCサーバを必要とする。

注5

μITRONのAPIはeSOL（株）のPrkernelV4を提供

注6

高機能開発用デバッガーとしてeSOL（株）のeBinderを装備。

56

渡辺政彦・石田哲史・戴志

電子開発学園出版局

14）日本工営技術情報利用したアーキテクチャであるため、実装部を切り離すこングを検討してから遷移表の設計を行うケースが多い。そ特集：組み込みシステムの開発環

13）リアルタイム環境へのCASE導入

発また、状態遷移表設計手法においては、制御動作タイミ

Architecture

計測自動制御学会

難しく遅れていた。DVCアーキテクチャはネットワークをとでオブジェクト指向へ対応できることから、オブジェク

翔泳社

DCOMはMicrosoft社の商標です。

JAVA、JINIはSUN

Micro systems社の商標です。