![[MNC]](images/intime.png "[MNC]")
製品の概要に関するFAQこのページは、INtime®製品の特徴や概要について、良くあるご質問と回答をまとめたものです。すでにINtime®製品をご使用でテクニカルなご質問については技術的なFAQをご覧頂けます。
1: 概要1-1: INtime®とは？
|
| INtime® | RTX | VxWorks | QNX | RT-Linux | WindowsCE | iTRON | |
| 対象CPU | x86 | x86 | 多数 | x86 | x86 | 多数 | 多数 |
|---|---|---|---|---|---|---|---|
| 処理量 | 32bit | 32bit | 8/16/32bit | 32bit | 32bit | 16/32bbit | 8/16/32bit |
| FileSystem |  |
|
/ |
|
|
|
|
| GUI | Windows x86/x64 | Windows x86 | 独自 | 特殊 | Linux | WinCE |
|
| Boot | |
|
|
|
|
|
― |
| 日本語対応 | |
|
|
|
|
|
― |
Windowsデバイスドライバなど特権レベル(Ring-0)で動作するソフトウェアがそのバグによりCPU例外を起こすと、青色の全画面表示（通称ブルースクリーン、BSOD）となりシステムハングアップを起こします。
INtime®ではWindowsがクラッシュしても制御を続行できるよう設計されています。
-INtime®がCPU専有モード、マルチカーネルモードで動作しているとき、WindowsとINtime®の動作するCPUコアは分離されます。このためWindowsのハングアップがINtime®カーネルに影響を与えることは物理的にありません。
-INtime®がCPU共有モードで動作しているとき、Windows全体は１つの低優先度スレッドとしてINtime®カーネルの管轄下で稼動します。INtime®はWindowsのハングアップを検知するとスレッド化されたWindowsを一時、サスペンド(停止)状態とし、その他のリアルタイムスレッドの動作は継続します。
INtime®は上位互換をポリシーとしたバージョンアップがされています。
原則、下位バージョンで構成されたINtime®アプリケーションは上位バージョンで再構築の必要なく動作できます。一般にはライブラリ類の不具合修正を含む場合もありますため、上位バージョン環境で再構築することをお勧めしています。
逆に上位バージョンで構築されたアプリケーションを下位バージョンで動作させることはできません。
バージョンアップに伴う新たなハードウェアメカニズムのサポートなどによって例外的にアプリケーションコードの見直しを強要されるケースも考えられますが、このような情報は随時ご提供させていただきます。
INtime®システムバージョンアップサービスはこちら
製鉄所の生産ライン、工作機械の採用実績が数多くございますので、24時間365日稼動は折り紙付です。
ただしハードウェアの側面から、工業用パソコンとして長期供給保証されている保守性・安定性に優れたモデルをお勧めします。PCの選定にお悩みがあれば弊社営業から適切なアドバイスが可能です
Windowsが動作できるインテルアーキテクチャPCの全てで動作できますが、コンピュータの性能によって発揮できるリアルタイム性能には違いがあります。弊社技術チームの性能評価が実施済みで動作適合と判断されたPC、弊社で予めINtime®をインストール、設定チューニングを施したINtime®プリインストールPCもご検討ください。
1:調達性
PCに使用されているWindowsOSは、他のOSと比べて、シェアが圧倒的に大きくマルチベンダーの為、PCハードの代替がしやすく調達性が良いです。2.機能拡張性
WindowsOSのシェアが大きい事から、システム開発に必要な技術・環境（VisualStudio等）が広く知られていて保守性が良いのと同時に、システムの機能拡張性が良いです。3.開発効率
Windows上で動作する市販のソフトウェアを利用する事も出来て、システム開発を効率良く行う事ができます。4.高性能ゆえのコストダウン
PCに使用されているIntel及びIntel互換のCPUは、マイコンやPLC等で使用されているCPUと比較すると処理能力が高く、複数のハードウェアで実現していた事を1台のPC上で同時並行的に処理できる為、ハードウェアのコストダウンが可能です。このように多くのメリットがある事から、PCを利用しています。
INtime®はWindowsを搭載したPCならば動きます。
しかしながらDellやHewlett-Packard、EPSON Directなどの、いわゆるコンシューマー向けPCのご使用は以下のような点に注意ください。コンシューマーPCはコーディング作業などの場面に於いては有効なものの、実際のデバッグ実行や、コントローラとしての運用には一般的に不向きです。またほとんどのノートPCにも類似した傾向があります。1: リアルタイム性能が優れない場合があります
コンシューマーPCは価格を据え置きながら性能を引き上げる目的でメーカーによる特別なチューニングが施される場合があります。例えばCPU動作周波数を定格以上にチューニング(OverClock)することで性能を高めたり、BIOSに埋め込まれた処理コードが周期的に消費電力を押さえるなどです。こうしたメーカーによるカスタマイズがINtime®の正確な時間周期(カーネルティック)能力に弊害をもたらす場合があります。2: 拡張ボードを利用できない場合があります
工業用途ではPCに数多くの拡張ボードやデバイスを増設する場合もしばしばあります。市販のバス拡張ユニットを用いて拡張スロットを増設したり、比較的大電流を制御する拡張ボードを用いることもあるでしょう。コンシューマーPCではこのような利用を想定していない場合もあり、バス拡張ユニットを挿入すると起動できない、拡張ボードを検出できない、電源容量不足、ノイズで短期間に故障してしまう・・・などがあります。
また、ハードウェア割込み機能を備えた拡張ボードをINtime®でリアルタイム制御するには、他のWindows管理下のデバイスとは分離された割込みリソースの確保が必要になります。コンシューマーPCではこのような配慮は期待できず、割込みリソースの確保が不可能な設計もあって、この場合拡張ボードのハードウェア割り込みをINtime®で扱えません。3: 長期的な保守や供給をできない場合があります
コンシューマーPCは主に製品価格に重点を置いており徹底したコスト削減策がとられています。たとえば製造時点で最も安価な電子部品を採用するなどの手法です。このため同じモデルであっても搭載されている電子部品が予告無く変更されたり、同モデルが数ヶ月先に販売終了するなどして、全く同じ性能を持つモデルを二度と手に入れられない場合もあります。4: 設置環境次第で著しく信頼性を損なう場合があります
コンシューマーPCは主に一般家庭やオフィスでの利用を想定しているため、工場内など温度や湿度変化の激しい場所、振動の生じる場所、サージノイズの生じる場所、粉塵を伴う場所などの環境耐性は考慮されていません。想定外の環境で利用すると設計よりも早く故障を招くなどして著しく信頼性を損なう場合があります。たとえばCPUファンの故障率は極めて高いように思われます。5: 運用中にSMIによりWindows OSを含む処理が一定時間割り込まれる場合があります
システムブートはBIOSからUEFIにシフトしていますが、UEFI仕様の一部に、SMI/SMMによりUEFI処理を必要とする機能を有効とするものがあります。この機能によりGPOSから機能情報を取得する処理実行時にSMIが発生し、RTOSを含むGPOSの処理が割り込まれます。IPC OEMベンダーには本懸念に対応し、実装時に本機能を無効にしたり、パラメータ設定にて無効にする機能を組み込んでいるケースがみられますが、コンシューマ向けPC上では機能無効化は考慮されていません。不定期なタイミングでSMI/SMMが発生し処理時間伸縮やシステムティックインターバルの欠落等が発生する可能性があり、結果としてハードリアルタイム制御に影響を与えることが考えられます。
当社では以上のような理由からコンシューマーPCをお使いのお客様へ確実なサポートを差し上げることが難しく、またライフサイクルの短さからINtime®適合性評価試験も実施しておりません。環境耐性や長期安定供給の保証されている工業用PCをINtime®Ready!としてご紹介している次第です。
INtime®は x86互換CPUでもご使用いただけます。
しかし互換CPUはキャッシュ挙動の違いなどから、適切なリアルタイム性能が発揮できない場合もありますので十分な評価をお奨めします。
もちろん使用可能です。
複数CPUコアのうち一部をINtime®専用に確保する動作モード（専有モード、マルチカーネルモード）をサポートしています。この構成ではWindowsとINtime®は異なるコアに区分けされ、非同期に、並列に動作可能であり、CPU共有モード動作時のようなOS環境切替オーバーヘッドを伴わない利点があります。
INtime®マルチカーネル機能はハイパースレッディングCPUでも使用できますが、ハイパースレッディングはもう一方のスレッディングと物理的共有部（キャッシュ）があることや、もう一方のスレッディングの命令内容に効率が依存することなどから、独立した物理コアによる実行と比べると、パフォーマンスは劣ります。これはハードウェアの特性になります。
使用できます。
Atom®プロセッサは、キャッシュサイズや浮動小数点演算ユニットなどがコンパクトな手段で代替されているため、一般的なデスクトップ向けプロセッサと比べると性能的に劣る部分もありますが、反面、価格面で有利なソリューションです。
弊社の工業用PC評価レポートでは、さまざまなメーカーのプラットフォームとINtime®の動作検証を行っておりますが、比較としてプロセッサ種別ごとにタスク切り替え性能の統計をとると下図のようになります。現在主流のプロセッサではタスク切り替えのオーバヘッドが約１マイクロ秒程度ですが、Atom®プロセッサでは3マイクロ秒～9マイクロ秒程度であります。
前述のように機能がコンパクト化されたAtom®プロセッサではソフトウェアで代替の必要な処理があるので、性能的に劣る点がありますが、社との技術連携によって、Atom®プロセッサでも優れたパフォーマンスを発揮できるよう、さらにINtime®を最適化する予定があります。
使用できます。64ビットWindowsもサポートしております（INtime®は32ビット動作）
旧INtime®バージョンをお使いのお客様には、EM64T/AMD64など64bit拡張機能を持つCPUを使用する際は注意すべき点がございます。詳細は下記リンクを参照してください。
INtime®にはWindowsに依存しない、INtime®上で駆動するネットワークドライバが付属しています。これをINtime®リアルタイムネットワークと呼んでいます。
INtime®のアプリケーションはソケットAPIを使用して、外部機器と通信が可能です。
Windowsが利用するネットワークコントローラと、INtime®が利用するネットワークコントローラは、それぞれ異なるハードウェア（コントローラ）に分離していただく必要があります。INtime®が対応できるネットワークコントローラは関連情報をご参照ください。
１つのコンピュータにおいて、INtime®から制御できるネットワークコントローラの同時使用上限は明確に決定されておりませんが、少なくとも４つのネットワークインターフェースを実現した事例がございます。
１つのコンピュータに複数のネットワークインターフェースを構成するには、NIC設定においてインターフェース定義(ETH0、ETH1...ETHn)を複数行います。１つのコンピュータに同型のネットワークコントローラを複数搭載して複数のインターフェースを構成する場合は、"inst="オプションによってネットワークコントローラのインスタンスを明確に指定します。
なお、１つのコンピュータに複数インターフェースを構成する際、同一ネットワークセグメントに複数のインターフェースを所属させることはできません。それぞれは異なるネットワークセグメントに所属する必要があります。
ノートPC用にデバイスを考える場合、カードの種類としてPCcardとPCMCIAの選択肢があります。共にその仕様上、利用の注意がありますのでまとめます。
PC Card
PCCardBusのデバイスはPCIデバイス相当なので、INtime®のPCIライブラリを使ってリソース割り当て状況を取得後、アクセスできます。しかしCardBusコントローラには必ず電源管理用のWindowsデバイスドライバが必要です。このときIRQリソースがWindowsと競合せざるを得ないため、INtime®アプリーケーションからPCCardデバイスのハードウェア割り込みは事実上使用できません。
PCMCIA
PCMCIAデバイスはISAデバイスでプラグアンドプレイに対応しないため、INtime®アプリケーションからは固定IRQと固定IOアドレスでアクセスします。PCMCIAコントローラには必ずリソース管理用のWindowsデバイスドライバが必要です。このためINtime®からPCMCIAデバイスを扱うには、特例的にWindowsドライバが適用されリソースの手動設定が行なわれている必要があります。
WindowsデバイスドライバはINtime®導入後も引き続き利用可能ですが、Windowsデバイスドライバを使う限りデバイスは真のリアルタイム動作にはなりません。INtime®スレッドによるデバイス制御に切り替えることによってリアルタイム動作となります。
リアルタイム性を保証するために、INtime®アプリケーションがWindowsデバイスドライバやＤＬＬを直接使用する手段は標準機能として提供しておりません。間接的な方法でINtime®アプリケーションからWindows機能を呼び出すサンプル(WindowsAPI呼び出しサンプル)が参考になります。
下記参照(2-12: ディジタルI/Oボード(Di/Do)のドライバはありますか？)
INtime®アプリケーションはポートI/O命令を直接コール可能なため、Windowsデバイスドライバのような概念を必須とせず、対象デバイスのコントロールレジスタ空間に直接アクセスできます。
* WindowsはWindowsアプリケーションから直接的なポートI/Oを許可していません。代わりにポートI/Oを
行うのはWindowsデバイスドライバであり、２つの構造とメッセージ通信によって制御が行われます。
たとえばディジタル入出力ボードやアナログ出力ボードなどをINtime®アプリケーションから扱うことは単純です。デバイスのI/Oレジスタマップ情報を参照しながら、レジスタ制御処理をライブラリ関数として記述いただくことで事足ります。たとえばデジタル入出力ボードの場合、C言語で数行のプログラミングで実現できます。
// 入力
data8bit = inbyte( parallelport );
// 出力
outbyte( LEDaddress , data8bit );
複雑な構造や、複雑な処理手順を持つデバイスの利用に多くのニーズがある場 合、INtime®アプリケーション用ドライバライブラリソフトとして提供していま す。このライブラリ関数を利用することでアプリケーション開発が簡略化できます。 どのようなドライバライブラリソフトがあるかは INtime®ウェブページの「関連製品」を参照ください。
INtime®は特別なドライバーを必要とすることなくバス拡張ユニットに対応することができます。
ただし、コンピュータがハード的に対応出来ない場合もありますので以下に補足いたします。
市販されているバス拡張ユニットは、あらゆるコンピュータに対して万能というわけではありません。BIOSレベルでの相性問題が比較的多く、コンピュータが起動しなくなったり、ボードが検出できないといった様々な問題を起こす場合があります。
たとえばA社製PCとA社製バス拡張ユニットの組み合わせはA社によって保証されますが、B社製PCとＡ社製バス拡張ユニットの組み合わせは保証されないケースも多く、しばしば問題となります。
一般的に原因はバス構成が拡張されることを想定していないROM-BIOSにあります。バス拡張ユニット選定の際には十分注意して、極力メーカーを揃えるような配慮をおすすめします。
（開発環境としての利用）
プログラミング環境としてVisual StudioとINtime®開発環境を導入し、ターゲットPCを接続したクロスデバッグ用途は問題なく使用できます。
（実行環境としての利用）
BIOSによるバッテリ残量の監視処理、ファンレス筐体内部温度制御のための動作クロック変動などが主な原因になり、INtime®カーネルはデスクトップPCのようなリアルタイム性能は一般に出せません。2msec, 5msec, 10msecといったオーダーの計測制御用途であれば概ね対応できます。
（拡張性の制約）
増設スロットを持つことのないノートPC環境での外部I/Oは必然的にEthernet、またはEtherCAT®になりますが、ノートPC搭載のNICはINtime®に適合していないものが見受けられますので事前に確認することを薦めます。
現在入手できるほぼ全てのWindowsバージョンへINtime®を導入することが可能です。（Windows95/98/Meは利用できません。）
Windows CEには対応しておりません。
Windows NT4.0、Windows 2000、Windows XP、Windows Vista、Windows 7とWindowsのバージョンアップに同期してそれぞれの対応を迅速に実施してまいりました。
INtime®は構造的にもWindowsのバージョンアップへ対応しやすくなっています。
動作が一切できなくなるような弊害を引き起こすウイルス対策ソフトウェアは確認されておりません。
しかしウイルス対策ソフトのファイヤーウォール機能がINtime®の通信機能を予期せずブロックしたり、スクリプトブロック機能がINtime®ユーティリティ類の動作を妨害したりする可能性も考えられます。また、自動アップデート機能によって、ある日突然問題を引き起こす可能性もあります。以上のような可能性がある事を考慮の上でを導入してください。
Visual Studio 5.0/6.0はすでに販売が中止されており、新規のご購入はできません。
Microsoft MSDN Subscriptionsのご加入で入手する方法があります。詳しくはMicrosoft MSDN Subscriptionsでご確認ください。
Microsoft社製 Virtual PCやヴイエムウェア社製 VMwareのような仮想化ソフトウェアを使用し構築されたWindows上環境にINtime®をインストール、実行することはできません。また仮想化ソフトウェア上ではリアルタイム性能が確保できません。
Windowsに対するリアルタイム機能拡張製品は他社からも販売されておりますが、INtime®と共存すること（同時にインストールすること）はできません。
NationalInstruments LabViewとINtime®アプリケーションの接続は以下のいずれかの方法で可能です。
Simulink Embedded Coderにより生成されたC/C++コードは純粋なANSI-C仕様範囲で作られた、処理系非依存のソースコードである限りINtime®アプリケーションからコールできる関数として使うことができます。 Visual Studioによるデバッグ実行（ステップ実行等）にも対応可能です。
INtime®を利用しているユーザーが、ホストOS(Windows)にVMを使ったUbuntu仮想環境とINtime®を1台のPCに共存させた事例があります。
INtime®はHyper-Vなどのハイバーバイザ仮想化と共存できませんが、ホストOS(Windows)上のバーチャルマシン(VM)による仮想化によって実現したようです。
| 仮想OS: Ubuntu 20.04.2 LTS 64ビット
| 仮想化ソフト: Oracle Virtualbox 6.1
| INtime: INtime 6.4.20030.1
| ホストOS: Microsoft Windows 10 Pro 64ビット
| CPU: Intel® Core™ i5-8600K 3.60GHz (6コアうち1つをINtime®)
| 実装メモリ: 16GB
基本的にTSS(タイムシェアリングシステム)方式をとるWindowsのリアルタイム性能を正確に測るのは困難です。動作させるアプリケーション、ドライバ、オペレーションの内容などさまざまな要因によって、複雑に変化します。
Windows XP, Pentium® 4 3.0GHzの環境で測定した結果では、割り込み応答速度が4μ秒～5μ秒程度、スレッド切り替えに要するオーバヘッド時間は0.9μ秒です。デュアルコアCPUではさらに高い応答性と安定性を実現できます。
INtime®のシステムコールについては以下の情報を参照してください。
設定は可能ですが、PCのスペック次第では実現できない場合があります。
概ねCore™2DuoクラスのCPUを目安としてください。
ご使用になるPCで100usが実現できるかどうかは、付属するINtime®GraphicalJitterツールで確認できます。
一般的な制御を行う上では影響は無いと言って問題ありません。しかし数マイクロ秒精度の極めて精密な制御を必要としている場合は、いくつかの要因により微量な影響を受ける場合があります。 詳しくは参考記事をご覧ください。
Windowsへ弊害が出ることは基本的にありません。しかしながらINtime®リアルタイムアプリケーションの開発においてはWindowsへ弊害を与えてしまう恐れのある処理を記述可能であることに気をつけてください。
INtime®リアルタイムカーネルと、WindowsとのインターフェースであるNTXは、単一のPC内のみでなく、ネットワーク接続された２つの異なるPC間インターフェースを考慮しています。これにより、柔軟なシステム構成が可能です。
ネットワークを利用したNTX接続では以下のいづれかにあたるPCが構築可能です:
- ハイブリッドノード(Windows + INtime®の単一PC構成)
- ローカルノード(INtime®のみで単独ブート)
- Windowsホスト(Windows環境にNTXインターフェースコンポーネントを導入)
NTX接続システムを使用しWindows⇔INtime®間の通信が可能であるため、以下のような組み合わせで通信が可能です。
- ハイブリッドノード ⇔ LAN ⇔ ハイブリッドノード
- ハイブリッドノード ⇔ LAN ⇔ ローカルノード
- Windowsホスト ⇔ LAN ⇔ ハイブリッドノード
- Windowsホスト⇔ LAN ⇔ ローカルノード
INtime®をマルチコアCPUで動作させる場合、専有モードと、共有モードがあります。（詳細）
専有モードでは、一つ分のCPUコアをリアルタイム制御専用に確保するため、リアルタイム処理の応答性能が向上します。ただしWindowsは一つ分のCPUコアを利用できなくなります。
このためWindowsで画像処理やシミュレーションなどの数値計算をするような場合で、Windows側のパワーをたくさん必要とする場合には共有モードが有利な場合があります。
付属するINtime® Graphical Jitter Displayツールが有効です。
このツールによって視覚的にわかりやすく、お使いのコンピュータにおけるリアルタイム性能を把握できます。
INtime®はWindowsファイルシステムを利用する仕組みになっていて、Windowsが取り扱える固定ディスクや、リムーバブルディスク、ネットワーク共有フォルダをリアルタイムアプリケーションから利用できます。
ただしWindowsファイルシステムを応用しているため、ファイルアクセスはリアルタイムではありません。
- 関連情報
INtime®はCPUアクセラレータではありません。
INtime®アプリケーションにおけるメモリアクセスも、Windowsアプリケーションにおけるメモリアクセスも同じCPU命令を使用してメモリアクセスを行います。このため性能に違いはありません。
INtime®のアプリケーションは特別な手続き処理の必要も無く、任意のタイミングで任意の空間にI/Oが可能です。提供しているI/O関数(マクロ)を使用したプログラミングができます。
I/O関数は単純にCPU命令へ置換されるもので、このCPU命令実行過程にINtime®が関与することは全くありません。
はい。適切に構成された環境上でのカーネルノード・アプリケーション動作はスケーラブルとなります。INtime®のクロックスケジューラは、ばらつきを最小としたクロックソースを基準としており、プライオリティに応じて動作中のタスクを切り替えます。このポリシーはタスク数やステップ数に左右されるものではありません。プライオリティの高いタスクは、より設計通りに動作し、プライオリティ、状況に応じてタスク切り替えが発生するため、その駆動タイミングや処理時間は変動的となります。
例えば、70個のタスクのうちプライオリティの高いタスクは、ほぼ想定通りの駆動タイミングで実行を行い、処理時間もほぼ定常となりますが、プライオリティが低くなるほど高プライオリティタスクに処理実行を阻まれる(プリエンプト)されることになるため、処理完了までの時間は変動的になります。それぞれのタスクが想定範囲内で動作するようにプライオリティを設計・調整によりスケーラブルな処理を実現します。
また、CPUの処理負荷が高い場合は、CPUのコア毎にカーネルを立ち上げ（マルチカーネルモード）その処理を分散することが可能です。処理の分散単位は、プロセスであるため、このような場合、一つのプロセス内に70個のタスクを包含するのではなく、複数に分割することになります。
アプリケーションの開発には、世界で最も使用されている統合開発環境Microsoft Visual Studioを使用します。
新規INtime®アプリケーションを開発するときは、追加機能INtime® Wizardの質問に答えていくことで自動的に骨組みが完成し、これに肉付けしていくことでアプリケーションが容易に完成します。ただしINtime®アプリケーションは拡張子RTAになる点が異なります。
INtime®の持つAPIはすべて電子ヘルプ化されており、スピーディな検索が可能です。
リアルタイムアプリケーションの開発はあくまでもC言語またはC++言語になります。リアルタイムアプリケーションは CPUのネイティブな命令語で動作することによって最大限の性能を実現いたします。
一方、GUI系の開発にはMicrosoft .NET frameworkとNTXシステムコールを組合わせて開発いただけますので、C#、VB、C++/CLIなどCLR対応言語で開発を行うことが可能です。.NET利用によるWindows GUIアプリケーションサンプルプログラム(%INTIME%\projects\ntxdotnetsampl)が収録されています。
リアルタイムアプリケーションの製作には使用できません。Microsoft社のコンパイラ(Visual Studio)が必要です。一方、HMI系の製作にはこれらサードベンダコンパイラの利用が可能です。（NTX.DLLの呼び出しができれば可能）
Windowsから利用可能なINtime® API(NTX)はDLLとして用意されています。
お客様に快適な開発をご提供するため情報を取りそろえるように注力しております。
開発システムにはサンプルプログラムが収録されています。もし開発中にシステムコールの使用方法がわからなければ、[F1]キー１つで日本語ヘルプへジャンプします。
ご覧のWebページでも、収録しきれなかったサンプルプログラムや、プログラミングテクニックを数多く掲載しています。
INtime®では、Visual Studio開発環境上でリアルタイムカーネル上のリアルタイムアプリケーションをデバッグ実行できます。I/O処理や割り込み処理のデバッグも可能です。実行中のリアルタイム制御アプリケーションへ接続（アタッチ）してのデバッグ、異なるPC間でのクロスデバッグ、ブレイクポイント、メモリダンプなど、Visual Studioが対応する全ての機能に調和いたしました。
他にも複数のデバッガーを持っており、ダイナミックソースコードデバッガSpiderDebugger、カーネル内蔵のシステムモニタSDMも利用できます。
INtime®アプリケーションはリアルタイム性を維持するために、DLLやWindowsAPIを直接的にはコールできないようになっています。
実現手法の１つとして、目的の既存DLLやWindowsAPIをコールするWindowsアプリケーションを実装して、INtime®アプリケーションからこのWindowsアプリケーションへ処理要求をかけて間接的に利用する方法があります。この手法はサンプルプログラムRTAからWindows機能を利用するや、RTAからWindowsをシャットダウンするが参考にできます。しかしこの方法の場合、従来通りWindowsによって処理されることになるためにリアルタイム性は改善されないことに注意してください。
第２の手法は、RSLとiWin32APIを利用してINtime®アプリケーションによって処理されるように移植してしまうことです。この手法ではリアルタイム性を保証可能です。INtime®ではリアルタイム共有ライブラリRSL（Real-time Shared Library）機能により、WindowsのDLLと同じ構造を実現できます。さらにiWin32APIテクノロジがWindowsで扱うWIN32APIの名称・動作をそのままに模倣します。ただし画面描画に関するWIN32API等は実装されていません。
次のような方法を用いることで、Visual BasicによるGUIアプリケーションを実現することが可能です。
- VCによる中継モジュール(DLL)を用意する
- NTX-APIを含んだActiveXコントロールを用意する
- Virtual Ethernetによる内部ネットワーク接続
- Visual Basic .NETをご利用の場合、INtimeDotNetを利用します。
社の開発した32ビットリアルタイムOS「iRMX®」とINtime®の間にはソースレベル互換がありません。しかしiRMX®を基本として開発されたINtime®は、システムコール名称は異なるものの、メールボックス、セグメント、セマフォ・・・等のオブジェクト使用方法は維持されていて基本的にはアーキテクチャに互換性があります
INtime®拡張製品リアルタイムOS iRFWでは100%旧来のiRMX®を継承した正規バージョンです。最も移行がスムーズです。
INtime®システムの運用中に突然電源が切れたとしても、次回のINtime®起動は通常通り行えます。
組み込み用途に適しているWindowxEmbeddedでは、EWF（エンハンスド・ライト・フィルタ）機能によって、ファイルを破損しない保証ができます。
UPS（無停電電源装置）の持つ停電検出時の接点信号出力をINtime®アプリケーションのハードウェア割り込み処理が受け入れるようにすれば、制御対象装置を数μ秒内で安全な状態へ誘導することができます。
timeなどのANSI-C関数はすべてサポートされています。
INtime®のインストールによって導入される、INtime®アプリケーション専用のCライブラリを使います。
CPUが搭載しているマルチメディア関連の拡張命令セット、SSE,SSE2,SSE3(Streaming SIMD Extensions)はVisual Studio 2005以降とINtime®バージョン3.x以降の組み合わせによって、INtime®リアルタイムアプリケーションでもお使いいただけます。関連情報をご参照ください。
ソースコードレベルのSTLはC++記述によるINtime®アプリケーションでお使いいただけます。
以下vector及びVectorarrayの使用例です。#include <valarray>
#include <vector>
#include <iostream>
#include <stdlib.h>
int main (void)
{
// vector
vector<int> array;
size_t i;
for( i = 0; i < 10; ++i )
{
array.push_back( i );
}
for( i = 0; i < 10; ++i )
{
cout << array[i] << " ";
}
cout << endl;
// valarray
valarray <int> arr(10);
size_t s = arr.size();
for ( i = 0; i < s; i++ )
{
arr[i] = i;
}
for ( i = 0; i < s; i++ )
{
cout << arr[i] << " ";
}
cout << endl;
return 0;
}
INtime®で行う制御にもよりますが、割り込みやイベント通知によるイベントドリブン方式の為、
ごくわずかな時間を専有し処理することになります。
空いた時間を全てWindowsへ制御を移す為、基本的には記述する必要はありません。
共有モードの場合、Windowsは最低優先度に位置する為、
Windowsの制御/更新も視野入れた設計の場合には、RtSleep 等による明示的な待機処理を入れる事で
その待機時間帯には、Windowsが制御/更新する事が可能になります。
同コアにWindowsが無い為、RtSleep等が不要のように思えますが、注意すべき点があります。
INtime®では、各スレッドに割り振った優先度によって制御されます。
開始準備が整っているスレッドの中で一番優先度が高いスレッドが動作します。
そのスレッドが、処理を終えた場合や待機に移った場合、次に開始準備が整っている優先度の高いスレッドが動作開始します。
しかし、そのスレッドが延々処理を行う場合、他の低優先度スレッド全ては延々待たされてしまいます。
もし、優先度が高く延々処理を行うようなコード(ポーリング等)が存在する場合、延々CPUを専有してしまい、
低優先度に位置するユーザースレッドや、INtime®ツール(INtime® Explorer等)が動作しなくなってしまいます。
この状態を許容する設計でない限り、RtSleep 等による待機処理を入れたり、イベントドリブン方式に変更したりする必要があります。
INtime® APIINtime®ソフトウェア開発モデルにおいて、一部を除き(デバイスの割り込みハンドラ)、ユーザコードはアプリケーションコンテキストで実行します。カーネル割り込みのISRコンテキスト相当でのアプリケーションスレッドを駆動させるためには、アラーム、タイマ等を使用し、カーネルからのシグナルを処理するコードを割り込み処理に準じたプライオリティ(130以降推奨)で実行します:
トレーサブルコントローラのトレース機能によって動作ログが取得可能です。
トレーサブルコントローラではコールするAPIの記録に加え、任意のログも記録できます。これらのログはトレーサブルコントローラ付属のツールや、トレーサブルコントローラ付属のクラスライブラリを用いて閲覧が可能です。
トレーサブルコントローラによるログ機能の最大の利点は、リアルタイム制御への影響を最小限に抑え、パフォーマンスを保ったまま動作ログを記録できる点です。
デバッグだけでなく、運用中も記録し続けることで万が一の障害時において、障害までの経緯を追う事が可能になります。
INtime®組み込みシステム(ランタイム）では実際の運用に必要な必要最小限の機能のみを実装しており、軽量化されています。開発版との機能の差については以下の関連記事をご覧ください。
INtime®をご購入頂くと開発キットがお手元に届き、次のものが含まれています。
- INtime®開発ライセンスシール （正規ライセンスの証明証）
- USBライセンスキー (開発時に挿入していただきます)
- INtime®インストールディスク
- INtime® QuickStart Guide本
開発キットに含まれなくてお客様に準備いただくものは次のとおりです。
INtime®はWindowsの動作するすべてのコンピュータに導入可能ですが、拡張性、リアルタイム性能、価格、保守体制などに個性があります。
マイクロネットでは、長期供給や堅牢性に優れた工業向けPCを中心に自主的な性能評価を実施しており、お客様のご予算とご要望に応じて、動作確認の済んだ一台をご提案できます。工業向けPCの長い経験で、拡張ボードの選定、OSのプリインストール、ストレージの選定など多様なカスタマイズに答えることも可能です。
どうぞ弊社営業担当にご相談ください。
御購入時に年間サポート契約をぜひご購入ください。電話や電子メールによる弊社技術エンジニアとの窓口を設置でき、開発効率が格段に高まります。緊急を要するサポートが発生した場合には、有償で弊社エンジニアが現地まで駆けつけるサービスも可能となります。また、有償技術トレーニングも割引で承ります。
トレーサブルコントローラとは、リアルタイムOS「INtime®」に制御データトレースの仕組みを組み込んだIoT対応に最適なリアルタイムOS製品です。
リアルタイムOS「INtime®」と互換の製品のため、従来INtime®をご利用いただいていたお客様もスムーズに移行することができます。
リアルタイム制御処理を作成するお客様が自分達で制御ログを採取する仕組みを設計する必要がないため、簡単に制御データを保存することができます。
保存したデータは、生産管理情報や品質情報、保守情報などとして活用することができます。
トレーサブルコントローラでは、リアルタイムな制御を実現するためのAPI自身に、データトレースの仕組みが組み込まれています。
「いつ、どのようなパラメータでコールされ、どういう結果になったか」というAPIのコール情報が保存されます。
それ以外にもリアルタイム性を阻害しない形での制御ログ保存APIなどが用意され、簡単に制御データを蓄積できるようになっています。
