CentOS 7にDAQ-Middlewareをセットアップ後yum updateするとomniORB関連でエラーがでます。どう対処すればよいでしょうか?

EPELリポジトリを有効にしているとDAQ-Middlewareをセットアップ後、yum updateで omniORBパッケージでエラーが発生してアップデートができません。 DAQ-MiddlewareパッケージではomniORB 4.1.7を使うように設定しています。 EPELにはomniORB 4.2.0があるのでEPELリポジトリが有効になっていると yum updateはomniORB 4.2.0に更新しようとします (がDAQ-Middlewareで4.1.7を指定しているのでエラーになります)。 対処として簡単なのはyum updateの対象からomniORB関連パッケージをのぞくことです。 /etc/yum.confの最後の行に

exclude=omniORB*

を追加してください。 これでyum updateでomniORB以外のEPELにあるパッケージも更新されます。

DAQ-MiddlewareはなぜRT-Middlewareを採用したのですか？

なぜ私たちはRT-Middlewareを採用したのでしょうか？従来、DAQの世界でもライブラリ・ドライバーレベルの再利用はよく行われていました。 共通するハードウエアを扱う場合は、ライブラリ・ドライバーを共通にして再利用して、各自の実験に即したDAQシステムを構築しました。 しかし、規模が大きくなりたくさんの計算機を使うようになるとシステム構築自体が難しくなりフレームワークが重要になってきました。 つまり、ライブラリ・ドライバーレベルの再利用だけでは各自の実験に即したDAQシステムの構築が難しくなってきたのです。 そこで、システムレベルの再利用が行われました。 すなわち、システムをできるだけ汎用化して、できるだけ多くの実験に対応できるようにしようというアプローチです。 しかし、現実にはそれぞれの実験ではそれぞれのDAQシステムが構築され、１つのDAQシステムがたくさんの実験に利用されるというようにはなっていません。 １つの理由はシステムレベルの汎用化は実験に即した効率化への対応に限界があるからではないかと思います。 そこで、ライブラリ・ドライバーレベルとシステムレベルの中間にコンポーネントレベルを設けて再利用可能にすることはできないかと考えました。 つまり、コンポーネントによる再利用です。それにはこのレベルの標準化が必要です。いままでこのような標準はありませんでした。 RT-Middlewareはコンポーネントレベルの国際標準なので採用したわけです。 機能的な面でさらに、実験においては単なるデータの収集・格納だけでなく、機器（ロボットも含む場合がある）の操作・モニタも含まれるため、 従来は機器の操作・モニタとデータ収集は別なシステムとして扱われていましたが、同じフレームワークで扱うことが可能になるというメリットもあります。

さて、私たちはRT-Middlewareの採用にあたり、DAQへの適用可能性をチェックしました。 すでにのべたように、RT-Middlewareはせまい意味でのロボットだけではなく広く組み込みへの適用も可能なフレームワークです。 しかし、その実装であるOpenRTM-aistの中身をみると、OpenRTM-aist-0.2.0の段階ではまだ組み込み系への適用に機能が不十分でした。 そこで、私たちは産総研と共同研究し、RT-Middlewareの改良を提案しました。現在も改良を続けています。 産総研との共同研究という点では、すでに1990年代後半からHORBと呼ばれる分散オブジェクト技術を利用したDAQシステムの共同研究が行われてきました。その成果の１つがK2Kニュートリノ実験ビームライン用DAQシステムでした。この共同研究の延長上に現在の共同研究があります。共同研究においては、単に産総研の成果物を利用するだけではなく、DAQシステムのような組み込み系のシステムのための機能改善や長期に渡る運転に伴う信頼性・安定性の検証などのフィードバックをかけて、協力関係を維持してきました。