タイの自動車部品メーカー向けの9ライン用生産追跡および運転比モニタリングシステム

課題の背景

本事例の課題は、全ラインの実生産数対目標と稼働率を単一のWebページで確認することでした。各ラインの生産数は、そのラインの機械とPLCにありました。製造部門は結果を昼勤・夜勤別に確認し、ラインの時間ロスにつながる問題を記録して、ロス時間の原因として最も多いものを把握したいと考えていました。

このお客様との業務は2020年に、大型画面のData Views（ライン情報表示画面）と、当社が手配したレンタルサーバー上のオンライン版Data Views 2ラインから始まりました。次の段階が全ラインを工場内サーバーに集約するシステムで、これが本事例の主要な業務です。

要件と制約

システムは工場の既存システムからデータを受け取り、内部ネットワークのみで動作する必要がありました。主な要件と制約は次のとおりです。

• 全9ラインの端末のData Shareから生産数を受け取り、工場内サーバーにオフライン（インターネット非接続）で取り込みます
• お客様のチームがData ShareとPLCの設定、サーバーハードウェアの調達、LANネットワークの構築を自ら行い、当社はデータ受信プログラムとWebページを開発しました
• 時間別の実績対目標を昼勤・夜勤別に表示します
• ユーザーは勤務時間帯、休憩時間帯、Takt Time（需要に応じて製品一個の生産に充てるべき時間）、OR目標を日付範囲ごとに自ら設定できます。休憩時間帯はロス時間として計算されません
• 問題を時間帯およびLoss A、Loss B、Loss Cのいずれかの区分とともに記録します
• 日次・月次・年次で過去データを確認し、PDFまたはExcelに出力します

本システムは複数ラインの生産数をどのように集約するのか

本システムは、各ラインの端末に既にあるData Shareから値を受け取って生産数を集約します。そのため、当社の業務ではPLCに直接接続する必要がありません。お客様のチームがPLCから生産数の信号を受け取るようData Shareを設定し、当社のプログラムがライン端末から値を取得して中央サーバーに保存し、実績対目標と稼働率を計算します。

このように業務を分担することで、各者の範囲が明確になります。機械とネットワークの側はお客様のチーム、プログラムと計算式の側は当社が担当します。要件文書でシステムをオフラインの内部サーバーに置くよう定めていたため、生産データは工場のネットワーク内にとどまります。この点は、レンタルサーバーを使用した初期段階のオンライン版Data Viewsとは異なります。

1. 1

   Data Shareから生産数を受信

   中央サーバー上のプログラムが、工場内ネットワークを通じて全9ラインの端末から生産数を取得します。

2. 2

   シフトと目標に基づく計算

   システムはユーザーが設定した勤務時間帯、休憩時間帯、Takt Time、OR目標を用いて、シフト内で時間ごとに得られるはずの生産数と累積のOperation Ratioを計算します。

3. 3

   実績対目標の表示

   生産状況ページは時間別の実績対目標を表示します。結果欄（Judge）は実績が目標に達すると緑、目標を下回ると赤で表示されます。

4. 4

   ロス時間の記録と分析

   ユーザーは問題、時間帯、Loss区分を記録します。システムは継続時間とシフトの勤務時間に対するロス時間の割合を計算し、円グラフとパレート図で表示します。

納入物

当社はOverall Monitoring Webアプリを納品し、工場内でIIS Webサーバー（WindowsのWebサーバー機能）として機能する産業用コンピューターSiemens SIMATIC IPC627E（Windows 10）に導入しました。全9ラインの生産ライン端末は、内部ネットワークのWebブラウザから閲覧します。

• 概要ページ: 全ラインの生産状況を単一ページで表示
• ライン別生産状況ページ: Takt Time、実サイクルタイム、累計実績対目標、緑と赤の結果欄を備えた時間別生産数の表
• 問題記録ページ: 問題、時間帯、Loss A、Loss B、Loss Cの区分と、システムが計算する継続時間およびロス時間の割合
• Operation RatioとLossの分析ページ: 棒グラフ、円グラフ、パレート図。日次・月次・年次、および昼勤、夜勤、両シフト合計を選択して表示
• シフト設定ページ: 日付範囲ごとの勤務時間帯、休憩時間帯、Takt Time、OR目標
• 各ラインのOR Board（稼働率サマリー画面）。そのラインのOperation Ratioページから開けます
• レポートのPDFとExcelへの出力

本システムはパイロットラインから他のラインへどのように拡張したのか

当社はパイロットラインでLossとOperation Ratioの計算をテストしながら、段階的にシステムを拡張しました。この方法により、他のラインに適用する前に実データで計算式を確認できました。業務の流れは次のとおりです。

1. 2020年: 大型画面にライン情報を表示するData Viewsと、当社が手配したレンタルサーバー上のオンライン版Data Views 2ライン
2. 2020–2021年: 工場内サーバー上でOverall Monitoringを開発し、パイロットラインでLossとOperation Ratioの計算をテストし、全9ラインの端末からWebを開くテストを実施
3. 2021年: お客様が実運用でテストし、当社が変更依頼書に基づいてリアルタイム計算と画面を調整したうえで、納品して正常に利用できるようサポート
4. 2022年: お客様から同じシステムを追加の生産ラインへ拡張するご依頼。対象は合わせてさらに11生産ライン

完了テストで確認できた成果

完了テストでは、全9ラインの生産ライン端末から、IISの再起動後も含めて中央サーバーのOverall Monitoring Webを開くことができました。パイロットラインでLossとOperation Ratioのページで計算でき、OR Boardも表示できました。本事例にはビジネス成果を測定した数値がないため、文書で確認できた結果のみを報告しています。

お客様が実運用でテストした後、当社は変更依頼書に基づいてリアルタイム計算と画面を調整し、すべての項目が当社チームの確認を通過しました。2021年に要件どおりに納品し、正常に利用できるようサポートしました。その後2022年に、この自動車部品メーカーから同じシステムを追加の生産ラインへ拡張するご依頼をいただきました。対象は合わせてさらに11生産ラインです。

私たちが学んだこと

本業務の主な教訓は、開発前に計算式と検収基準を合意すること、シフト途中のデータでテストすること、全ラインのデータソース担当者を決めることです。

• 開発を始める前に、計算式と検収基準を明確に合意します。本業務では途中で要件が変わり、テストと検収の範囲も当初から合意されていませんでした。そのため、お客様のテスト後に変更依頼書に基づく調整が必要になりました。
• テストセットには、シフト終了時のデータだけでなくシフト途中のデータも必要です。本業務の当初のテストセットには終日のシフト終了時のケースしかなかったため、シフト途中のリアルタイム計算は、お客様の実運用後に調整が必要になりました。
• 複数ラインのデータを集約するシステムでは、データソース側の担当者を明確にし、全ラインのデータがすべて入っていることを確認する必要があります。本業務では、一部ラインの生産数が断続的にシステムへ入らないことがありました。役割分担を明確にしておくことで、Data Share側とプログラム側のどちらを確認すべきかが分かります。

この手法をお客様の工場に適用する方法

貴社の工場に複数の生産ラインがありシフト制で稼働している場合、本事例と同じ手法を利用できます。ラインの既存システムから生産数を受け取り、シフトとTakt Timeに基づいて目標と比較し、ロス時間の原因を区分ごとに記録する方法です。調整が必要になるのは、貴社のラインにData Shareのようなデータ送信システムがない場合の生産数の受け取り方法です。

• 各ラインのシフト、休憩時間帯、Takt Time、目標のデータを準備します。これらはすべてのページの計算の基準となるためです
• シフト終了時とシフト途中の両方のテストデータセットを準備します
• 拡大する前に実データで計算式を確認するため、パイロットラインを一つ選びます
• 設備側、ネットワーク、プログラムをそれぞれ誰が担当するかを明確に取り決めます