復刻:キーワードガイダンス第17回「仕向けと地域化」 ― 2014年05月24日 06時00分59秒
初出:技術評論社「組込みプレスVol.19」(平成22(2010)年5月6日発売)
●海外製品とOEM製品
日本で発売される製品と同じ外観、同じデザインのものが海外で販売されているのを目にすることも多いと思います。
ですが日本で売られているものと細かいところで異なる点もあります。
(a) 型番や製品名
(b) 機能の増減
(c) 表示される言語の違い
(d) 電圧などの違い
(e) 物理的な配置の違い
自社のブランドをつけた市販品と他のメーカに製品を供給して供給先のブランドとして販売されるようなOEM製品という扱いもあります。
これは日本のメーカでは「仕向け」という言葉で表現されます。
本来は単なる「送り先」というような意味ですが、基準となる製品の派生製品を指す場合に使われる言葉です。
●部品の共通化
メーカでは派生製品を製造する場合には出来るだけ部品を共通化することが行われます。
同じ部品を数多く使う方が製造原価が下がるためです。
但し、ここでいう「共通部品」というのはハードウェアについてのことであり、多くの場合ソフトウェアは含まれていません。
このため、ソフトウェアの共通化を視野に入れて設計を行う要求仕様そのものが発生しません。
共通化を最初に視野に入れるかどうかで派生製品の開発のやり方が全く異なってしまうのですが、共通化するための設計および実装工数は配慮されないままに開発が行われることになります。
製造原価という視点では開発工数が増加するかどうかはあまり問題視されないからです。
●国際化と地域化
PCで動作させるソフトウェアでは国際化(internationalization)と地域化(localization)という思想でソフトウェアが組み上げられることが一般的になっています。
主に日本語や中国語のようなマルチバイト言語の切り替えに対する配慮が共通部品として提供されているような仕組みです。
共通部品化されたソフトウェアをベースにアプリケーションを開発すれば、言語切り替えの仕組みに対する切り替え処理と定義データの差し替えを行うだけで、ソフトウェアの処理ロジック部分には手を加えることはなく、製品を開発することができます。
このような考え方は開発工数の削減には非常に有効なものです。
このように、地域化は国際化を前提とした対になる表現ですが、「仕向け」はソフトウェア上の「共通部品化」を前提には考えられていません。
そして、組込みソフトウェア開発以外では「仕向け」という言葉が使われることはほとんどなく、汎用的なOSを使わないような組込みソフトウェア開発では
「ローカライズする」というような言葉が使われることもほとんどありません。
●仕向け対応の実際
このような状況で、汎用的なOSを使わない組込みソフトウェアの開発では以下のような開発が現実には行われることになります。
(1) 基準製品の開発時の開発予算には共通部品化の予算は含まれていない
(2) 仕向け対応はその製品単位の要求仕様を満たすものだけが行われる
(3) 仕向けの切り替えは動作中には行われないものとして設計される
(4) ソースプログラムに複数の仕向け用の記述を網羅してコンパイルの
段階で切り替えられるようにする
(4)の対応で充分にソフトウェア開発上の問題は解決しているように見える場合はもちろんありますが、実際には仕向けの組み合わせによってタイミングが異なることもあり、正常動作していたはずのソースプログラムにまで手直しが必要な場合もあります。
例えば、A機能、B機能、C機能の処理ブロックがある場合、A機能だけの仕向け製品、B機能だけの仕向け製品、C機能だけの仕向け製品というような場合には正常に動作していても、A機能とC機能を組み合わせた仕向け製品では正常に動作しないということがあるわけです。
また、A機能、B機能、C機能を全て有効にするような仕向けが発生した場合、プログラムを格納するROM領域が足りなくなったり、使用するRAM領域が足りなくなるようなことが考えられます。
単純にハードウェア部品としてROMやRAMのサイズを増やせるような場合はソフトウェアに対する影響は少ないものになりますが、製造原価に直接響くような対応は後回しにされます。
このような場合はROMやRAMのサイズを増やさないでも納まるようにソフトウェア全体を見直して作り変えることが第一に検討されます。
●海外製品とOEM製品
日本で発売される製品と同じ外観、同じデザインのものが海外で販売されているのを目にすることも多いと思います。
ですが日本で売られているものと細かいところで異なる点もあります。
(a) 型番や製品名
(b) 機能の増減
(c) 表示される言語の違い
(d) 電圧などの違い
(e) 物理的な配置の違い
自社のブランドをつけた市販品と他のメーカに製品を供給して供給先のブランドとして販売されるようなOEM製品という扱いもあります。
これは日本のメーカでは「仕向け」という言葉で表現されます。
本来は単なる「送り先」というような意味ですが、基準となる製品の派生製品を指す場合に使われる言葉です。
●部品の共通化
メーカでは派生製品を製造する場合には出来るだけ部品を共通化することが行われます。
同じ部品を数多く使う方が製造原価が下がるためです。
但し、ここでいう「共通部品」というのはハードウェアについてのことであり、多くの場合ソフトウェアは含まれていません。
このため、ソフトウェアの共通化を視野に入れて設計を行う要求仕様そのものが発生しません。
共通化を最初に視野に入れるかどうかで派生製品の開発のやり方が全く異なってしまうのですが、共通化するための設計および実装工数は配慮されないままに開発が行われることになります。
製造原価という視点では開発工数が増加するかどうかはあまり問題視されないからです。
●国際化と地域化
PCで動作させるソフトウェアでは国際化(internationalization)と地域化(localization)という思想でソフトウェアが組み上げられることが一般的になっています。
主に日本語や中国語のようなマルチバイト言語の切り替えに対する配慮が共通部品として提供されているような仕組みです。
共通部品化されたソフトウェアをベースにアプリケーションを開発すれば、言語切り替えの仕組みに対する切り替え処理と定義データの差し替えを行うだけで、ソフトウェアの処理ロジック部分には手を加えることはなく、製品を開発することができます。
このような考え方は開発工数の削減には非常に有効なものです。
このように、地域化は国際化を前提とした対になる表現ですが、「仕向け」はソフトウェア上の「共通部品化」を前提には考えられていません。
そして、組込みソフトウェア開発以外では「仕向け」という言葉が使われることはほとんどなく、汎用的なOSを使わないような組込みソフトウェア開発では
「ローカライズする」というような言葉が使われることもほとんどありません。
●仕向け対応の実際
このような状況で、汎用的なOSを使わない組込みソフトウェアの開発では以下のような開発が現実には行われることになります。
(1) 基準製品の開発時の開発予算には共通部品化の予算は含まれていない
(2) 仕向け対応はその製品単位の要求仕様を満たすものだけが行われる
(3) 仕向けの切り替えは動作中には行われないものとして設計される
(4) ソースプログラムに複数の仕向け用の記述を網羅してコンパイルの
段階で切り替えられるようにする
(4)の対応で充分にソフトウェア開発上の問題は解決しているように見える場合はもちろんありますが、実際には仕向けの組み合わせによってタイミングが異なることもあり、正常動作していたはずのソースプログラムにまで手直しが必要な場合もあります。
例えば、A機能、B機能、C機能の処理ブロックがある場合、A機能だけの仕向け製品、B機能だけの仕向け製品、C機能だけの仕向け製品というような場合には正常に動作していても、A機能とC機能を組み合わせた仕向け製品では正常に動作しないということがあるわけです。
また、A機能、B機能、C機能を全て有効にするような仕向けが発生した場合、プログラムを格納するROM領域が足りなくなったり、使用するRAM領域が足りなくなるようなことが考えられます。
単純にハードウェア部品としてROMやRAMのサイズを増やせるような場合はソフトウェアに対する影響は少ないものになりますが、製造原価に直接響くような対応は後回しにされます。
このような場合はROMやRAMのサイズを増やさないでも納まるようにソフトウェア全体を見直して作り変えることが第一に検討されます。
復刻:キーワードガイダンス第18回「仮想化」 ― 2014年05月24日 06時36分31秒
初出:技術評論社「組込みプレスVol.20」(平成22(2010)年11月6日発売)
※この号を最後に予告なく「休刊」
●インターネットと仮想
インターネットコミュニティ上の「仮想世界」、仮想世界で本物のお金と同じように機能する「仮想通貨」、仮想世界での自分の分身である「アバター」などが「仮想」に関連した言葉として一般的にも浸透しています。
「クラウドコンピューティング」という言葉も流行っています。
こちらもサーバ、ストレージ、ネットワークなどのハードウェア資源をインターネット環境で仮想的に扱うための概念です。
仮想化の特徴は以下になります。
(1) 仮想化する前の実体(リソース)が既知である
(2) 仮想化された後の実体は仮想化される前の実体と同じように見える
●仮想化の分類
このようにコンピュータの世界での「仮想」とは物理的な何かをシステム上置き換えた「代替物」であるということが出来ます。
そして、「仮想化」は「仮想」を扱うための仕組みです。
ここでは「仮想化」を以下のように分類します。
(a) ユーザインターフェースの仮想化
(b) 言語処理系の実装表現としての仮想化
(c) ハードウェアリソースの仮想化
インターネットコミュニティ上の「仮想化」はユーザインターフェースの可視化のためにアバターを定義して、その仮想世界の提供者の収益を上げるために仮想通貨を定義しているに過ぎません。
言語処理系としてJava言語に対するJavaVM(Java Virtual Machine)は「仮想」という言葉が使われています。
しかし、JavaVMは実装的視点では単なるインタープリタやコンパイラによるコード翻訳の一つの形態と見なすことが出来ます。
Javaバイトコードは独自に定義されたコードであり、他の既存のCPUの命令コードを置き換えたもの(エミュレートしたもの)ではありません。
●仮想化の実装方式
ハードウェアリソースの仮想化の例として「ハイパーバイザ(hypervisor)」という技術があります。
この技術ではJavaVMと同じように「仮想マシン(Virtual Machine)」という言葉が使われます。
ハイパーバイザはCPUを含むハードウェアリソース一式を仮想化して仮想マシンを定義します。
仮想マシンは仮想マシン上で動作するソフトウェアから見るとハードウェア実体そのものに見えます。
仮想マシンは独立していてそれぞれが別々のOSを動作させることが出来ます。
この時、実体としてのハードウェアは一つで構いません。
ハイパーバイザはハードウェアと仮想マシンの間に介在してエミュレーション動作することになります。
「仮想化」には以下の種類があることになります。
(A) 可視化の手法としての仮想化
(B) 変換・翻訳機能(トランスレータ)
(C) 既知の何かに見せかける機能(エミュレータ)
●組込みシステムと仮想化技術
組込みシステムの開発を中心に考えた時、有効となる仮想化技術はトランスレータ(translator)とエミュレータ(emulator)です。
仮想化階層を利用する側から見ると従来から実在するハードウェアやソフトウェアに対するインターフェースと同等に機能することが必要です。
実際には仮想化階層の先にある物理インターフェースとの機能差の程度によってトランスレータとエミュレータは使い分けられることになります。
単純な手順の変換だけで済む場合はトランスレータで完結することになりますが、複雑な機能の場合はエミュレータとして実装することになります。
ターゲットとなる実機のソフトウェア構造にこのような仮想化の仕組みが組込まれていればハードウェアリソースに対するアクセス処理は共通に記述することが出来るためハードウェアの物理的な属性や拡張に依存しません。
ハードウェアの物理的属性に依存する部分は仮想化技術階層部分で吸収することができます。
結果として開発効率、再利用性が上がり、品質向上にも寄与します。
また、実機をエミュレートする仮想的な実機がPC上で動作すれば実機なしに開発およびデバッグを行うことも可能です。
一方で仮想化階層が介在することによるオーバーヘッドを考慮する必要があります。
※この号を最後に予告なく「休刊」
●インターネットと仮想
インターネットコミュニティ上の「仮想世界」、仮想世界で本物のお金と同じように機能する「仮想通貨」、仮想世界での自分の分身である「アバター」などが「仮想」に関連した言葉として一般的にも浸透しています。
「クラウドコンピューティング」という言葉も流行っています。
こちらもサーバ、ストレージ、ネットワークなどのハードウェア資源をインターネット環境で仮想的に扱うための概念です。
仮想化の特徴は以下になります。
(1) 仮想化する前の実体(リソース)が既知である
(2) 仮想化された後の実体は仮想化される前の実体と同じように見える
●仮想化の分類
このようにコンピュータの世界での「仮想」とは物理的な何かをシステム上置き換えた「代替物」であるということが出来ます。
そして、「仮想化」は「仮想」を扱うための仕組みです。
ここでは「仮想化」を以下のように分類します。
(a) ユーザインターフェースの仮想化
(b) 言語処理系の実装表現としての仮想化
(c) ハードウェアリソースの仮想化
インターネットコミュニティ上の「仮想化」はユーザインターフェースの可視化のためにアバターを定義して、その仮想世界の提供者の収益を上げるために仮想通貨を定義しているに過ぎません。
言語処理系としてJava言語に対するJavaVM(Java Virtual Machine)は「仮想」という言葉が使われています。
しかし、JavaVMは実装的視点では単なるインタープリタやコンパイラによるコード翻訳の一つの形態と見なすことが出来ます。
Javaバイトコードは独自に定義されたコードであり、他の既存のCPUの命令コードを置き換えたもの(エミュレートしたもの)ではありません。
●仮想化の実装方式
ハードウェアリソースの仮想化の例として「ハイパーバイザ(hypervisor)」という技術があります。
この技術ではJavaVMと同じように「仮想マシン(Virtual Machine)」という言葉が使われます。
ハイパーバイザはCPUを含むハードウェアリソース一式を仮想化して仮想マシンを定義します。
仮想マシンは仮想マシン上で動作するソフトウェアから見るとハードウェア実体そのものに見えます。
仮想マシンは独立していてそれぞれが別々のOSを動作させることが出来ます。
この時、実体としてのハードウェアは一つで構いません。
ハイパーバイザはハードウェアと仮想マシンの間に介在してエミュレーション動作することになります。
「仮想化」には以下の種類があることになります。
(A) 可視化の手法としての仮想化
(B) 変換・翻訳機能(トランスレータ)
(C) 既知の何かに見せかける機能(エミュレータ)
●組込みシステムと仮想化技術
組込みシステムの開発を中心に考えた時、有効となる仮想化技術はトランスレータ(translator)とエミュレータ(emulator)です。
仮想化階層を利用する側から見ると従来から実在するハードウェアやソフトウェアに対するインターフェースと同等に機能することが必要です。
実際には仮想化階層の先にある物理インターフェースとの機能差の程度によってトランスレータとエミュレータは使い分けられることになります。
単純な手順の変換だけで済む場合はトランスレータで完結することになりますが、複雑な機能の場合はエミュレータとして実装することになります。
ターゲットとなる実機のソフトウェア構造にこのような仮想化の仕組みが組込まれていればハードウェアリソースに対するアクセス処理は共通に記述することが出来るためハードウェアの物理的な属性や拡張に依存しません。
ハードウェアの物理的属性に依存する部分は仮想化技術階層部分で吸収することができます。
結果として開発効率、再利用性が上がり、品質向上にも寄与します。
また、実機をエミュレートする仮想的な実機がPC上で動作すれば実機なしに開発およびデバッグを行うことも可能です。
一方で仮想化階層が介在することによるオーバーヘッドを考慮する必要があります。
最近のコメント