第154回 設計部門BOM改善コンサルの現場から～その83～ソフトウェアのE-BOM管理の考え方 具体編

1. PLC＋リレーシーケンスを継続する（継続せざるを得ない）。

最も大きな要因はソフトウェア・エンジニアリングとしての技量の問題です。
ある中小製造業の社長からは「谷口さんの言うことは分かるけど、そのような高い技量を持ったエンジニアはわが社には来てくれないよ」と言われます。現実としては認めるところですが、そうであっても「生き残り」という企業としての最重要課題に対する経営姿勢が大いに問われるところです。

頭数ではありません。優れた技量を持ったエンジニア1人がこの窮状を救う可能性がありますし、そのような現実を見て来ました。要は、そのようなエンジニアを見いだし、招聘（しょうへい）するための特別な待遇も併せて、経営者としての決意の問題だと考えています。「給与バランスがうんぬん」などという低い次元の話ではありません。

2. PLCは継続使用するが、リレーシーケンスのみという現状から脱却を図り、世界標準の言語体系（Ex, IEC 61131-3）などを導入して、制御の高度化、複雑化に対応する。

世界標準の言語体系導入によって、「顧客側保守エンジニアの理解も得やすい」という利点は大きいと思います。つまり「高価なPLCは継続して購入するが、それを制御する言語体系を改革していこう」というものです。

まずは言語体系から革新して、流用化・標準化設計に持ち込もうという考え方は賛成です（ソフトウェア・ファースト）。
IEC 61131-3の体系詳細に関しては多くの資料が存在しますので、別途一読してください。ここでは簡単に触れておきます。

IEC 61131-3は下記の5種類の言語体系を備え、おのおの得手不得手の制御方式に対して、混用も含めてソフトウェアの効率を上げて行くことを前提としています。

これら5種類の最も大きな相違は
（1）LD、（2）FBD、（3）SFC言語は、「グラフィック表現」（図やチャートによる表現）
（4）ST、（5）IL言語は、「テキスト表現」（いわゆるソースコード表現）
であることです。

共有のしやすさはグラフィック系の方が勝っていますが、ソフトウェア効率としてはテキスト系が優れています。これら5種類の言語をどのように組み合わせて、混用していくべきか？ ソフトウェア設計者同士でルール化します。このルール化の策定過程で他人に理解できる（共有できる）ドキュメントをどうすべきか？ の検討が必須になります。
何より「蛸壺設計」からの離脱を目指すためのルール化への第一歩といえるでしょう。

3. 高価なPLCから安価な「組み込み型」CPUを高級言語（Ex, C++）＋低級言語（Ex, アセンブラ）を駆使（混用）して、分散処理を可能にしていく。

安価で使いやすく、産業用として信頼性を確保した組み込み型CPUが多く出回ってきています。
驚きは教育用途のはずであった（？）ラズベリーパイ（ラズパイ）もOSを搭載した産業用が出現。価格もラズパイ価格、とこれも驚きです。制御系のコストダウンの近道としてはもちろん、IoTのフロントエンド分散処理用としても、大いに活用したい市販組み込み型CPUの一例です。

そのような環境の中、「まずは、ソフトウェア改革から」というアプローチです。
ソフトウェア情報の共有化、流用化・標準化を目指すための効果的なステップ、手段だと考えています。ソフトウェア設計者の各種言語に対する得手、不得手を解消するためにIEC 61131-3はもとより、高級言語（C++, C#など）や処理ステップ数をコントロールしてタイムアウトを防ぐ時に有用な低級言語（アセンブラなど）ぐらいは扱えるように教育の機会を積極的に設けることも必要でしょう。

その後、これら言語をどのように混用してハイブリッド化していくべきなのか、理解した設計者同士で検討を進めることが大変重要です。不得手な言語を毛嫌いするあまり、得意な言語に執着してしまうことを許す「蛸壺設計」環境からの脱却がいかに重要なのか理解してもらえると思います。

4. 組み込み型CPUとそれを制御する「理解しやすい中間言語」も含め「全て自社開発」として、顧客側保守エンジニアにも優しい中間言語体系の開発と制御系のコスト低減の双方を目指す。自社製PLCと言語の実現。

この手段は大変効果があります。しかし、技量の高いソフトウェア設計者のみならずハードウェア設計者も同時に必要です。しかし、私は最終的にこの手段を選択しました。苦労はありましたが流用化・標準化も含めたソフトウェア設計効率向上や制御系コスト低減という難題を同時にかなえることができました。

最も効果があったことはソフトウェア、ハードウェアという設計カテゴリーの壁が取り払えたことです。制御系設計者はハードウェアもソフトウェアも扱える技量を保持することができたことは設計者自身、成長を感じられることができたと考えています。

実際にどのように行ったのか？ をここで述べるとページ数に際限がなくなってしまいますので、コンセプトのみにとどめましょう。

もう一つは、メモリーを大容量SSD（その当時は高価だった。当初はRAM＋バッテリー）として、ある自動機のシリーズ（派生機種も含め）のオブジェクトを全て搭載させました。おのおのの機種に応じてDIPスイッチなどでスタートアドレスやトレースアドレスを変えて、機種に応じた制御ソフトを走らせるというアイデアです。細かなパラメーター（タイマーなど）変更もあらかじめテーブルを用意して、ユーザー側の中間言語で自由に選択できる引数マクロ形態にするなどのアイデアも顧客の保守部門には喜ばれた記憶があります。

既に気づきがあると思いますが、ソフトウェアの大きな特質として100ステップだろうが10万ステップだろうがSSDの物理的な大きさは変わりません。つまり永久にトレースされないステップがあっても誰も気にしません。このソフトウェア特有の特徴はメカ系、エレキ系ではかなわないメリットだと考えていますし、故に有効に使いたいものです。
少なくとも「この自動機のソフト、どこにあるの？」はなくなります。