混在率の高い環境における製造アプリの活用法

多品種環境での製造アプリの使い方

Tulipを使用した多品種環境での作業指示の設定方法をご紹介します。

このガイドでは、次のことを学びます。

• Tulipの機能を組み合わせて多品種環境に適合させる方法。
• Tulipでバラツキを処理する各アプローチの長所と短所

店頭で何百ものSKUを管理していますか？あるいは、複数の製品ラインにまたがって再利用される一連のプロセスを持っていますか？

このガイドでは、Tulipが製品内の高いばらつきを処理するのに役立つさまざまな方法をすべて取り上げます。

多品種環境」を生み出す要因は複数あるため、Tulipにはすべての多品種シナリオをカバーできる単一のツールや機能はありません。代わりに、状況に応じて複数の機能を組み合わせることになります。主な要因は以下の通りです：

• 接続デバイス数
• SKU間のばらつき
• Tulipデータの分析要件
• 製品の「ファミリー」が存在するかどうか

一般的に、多品種を扱うには5つの異なる方法がある：

• **アプリ：**アプリ：各製品、または各製品ファミリーに特化したアプリを作成する。
• **ステップ：**ステップグループのさまざまな組み合わせを作成する
• **テーブル：**複数のステップを作成することなく、テーブルから作業指示データを動的にロード
• **トリガー：**If "ステートメントまたは文字列連結を使用して、何百もの組み合わせを処理する。
• **SQL：**過去に SQL を書いたことがあれば、Connector 関数を使用して外部 SQL データベースと連携できます。

これらの各機能で使用できる戦略をいくつか紹介します。

注意：このガイドは、アプリ構築の経験がある Tulip ユーザを対象としています。まだアプリを構築したことがない場合は、Tulip Basicsから始めてください。

アプリ

複数のアプリを活用して複雑さを管理するには、2つの方法があります。

1つ目は、商品やSKUごとに個別のアプリを作成し、1つのルーティングアプリを使ってオペレーターを自動的に適切なアプリに送る方法です。これは、フロアにある商品の作業指示の重複が限られている場合に効果的です。

ルーティングアプリの完全ガイドはこちら。

これを実現するには、「ルーティング」というワンステップアプリを作成します。これは、デフォルトでフロアのすべてのステーションで実行されるかもしれません。オペレーターが新しい作業指示を始めると、作業指示をスキャンし、自動的に正しいアプリに誘導されます。

このステップは、チューリップ・ターミナルのこのステップのように見えるかもしれない。

そして、ステップ上の1つのトリガーに一連の "If "ステートメントを書いて、オペレータを正しい指示セットにルーティングします。

SKUが "1A2B3X4D "の製品のIf文は以下のようになります。

オペレーターがルーティングアプリでバーコードをスキャンした場合、このデータを次のアプリに渡す方法を見つける必要があります。このガイドを使って、アプリ間でデータを渡す方法を学んでください。

そして、オペレーターがSKUを打ち間違えて間違ったアプリに入ってしまわないように、すべてのアプリの最初に何らかの確認を含めることができます。

包括的な指示セットによるアプリの複製

すべてのアプリが一連の手順のサブセットを使用している場合、「複数のアプリ」アプローチを使用することもできます。これは、製品間で共通する手順が多い場合に有効です。

まず、複数の製品またはSKUで使用されるすべてのステップを含む「一般テンプレート」アプリを1つ作成します。次に、各商品ごとに、アプリを複製し、その特定の商品に関係のないステップをすべて切り出します。

このようなアプリベースの戦略は、すべてのトリガーがシンプルなので、チューリップの新規ユーザーでも簡単に管理できます。1つのアプリを1つの製品に」というパターンは理解しやすい。しかし、個々のステップのデザインを変更したい場合、このアプローチではアプリごとにステップをやり直す必要があります。

ステップ/ステップグループ

製品に似たような作業手順がある場合、個々のステップやステップグループをよりダイナミックにすることもできます。複数のアプリを作成するのではなく、1つのアプリ内に多くのステップグループを作成し、トリガーロジックでステップグループを通してオペレータをルーティングすることができます。

上のセクションの例のように、バーコードスキャンステップを含めることもできます。そして、バーコードをアプリの完了に結びつけ、オペレータを正しいステップにルーティングするために、バーコードデータを変数として保存したいと思うでしょう。

バーコードデータはアプリ内に保存されているので、トリガーを使って複数の方法で作業指示を組み替えたい場合、後で参照することもできます。

これにより、Tulipのメインインターフェースから、すべての作業指示ステップを一箇所で簡単に更新できます。しかし、数百、数千のSKUがある場合、さらに簡単にリアルタイムでステップを更新し、リードオペレーターやスーパーバイザーがリアルタイムで変更できるようにしたいと思うかもしれません。

各作業指示セットをリアルタイムで更新するには、いくつかのフィールドを持つフォームステップを使用します。各作業指示ステップに以下のフィールドがあるとします：

1. 主な指示見出し
2. 指示の詳細
3. 画像
4. 特記事項

このようになります：

これらの指示をリアルタイムで更新するには、このようにフォームステップを使用します：

次に、結果をテーブルまたはSQLデータベースに保存し、オペレータがアプリを通過したときに「ステップ番号」フィールドに基づいて動的に取得することができます。ここではその方法を説明します。

テーブル

Tulipのテーブル機能では、コードを記述することなく、アプリのデータや指示のセットを含むデータベースを作成できます。以下のような場合に、説明書として使用できます：

1. すべての製品に異なる命令セットがある。
2. 製品は、キャスティング、クリーニング、監査などの一連の共通プロセスを共有しており、それらのプロセス内にはほとんどばらつきがない。

また、指示書の各ステップは、1つの見出し、1セットの詳細、1つの画像など、同じ内容でなければなりません。

もし、あなたの作業指示がこの2つのカテゴリーのどちらにも当てはまらないのであれば、表はあまり適していないかもしれません。

しかし、これらのパターンのいずれかに当てはまるのであれば、テーブルから作業指示を動的に読み込む、たった1ステップでアプリを作成することができます。

まず、このようなフィールドを持つテーブルを作成する：

次に、少なくとも1つのレコードを追加する：

次に、アプリを作成し、すべての作業指示を動的にロードする1つのステップを作成します。テーブル・レコード "テキスト・ウィジェットを使用して、オペレータが進行する準備ができ次第、ステップ上のテキストと画像を変更します。

以下は、"Table Record" ウィジェットのフィールドを使用するレイアウトのサンプルです：

次に、オペレータが "Next "ボタンを押しても、次のステップには進みません。代わりに、テーブルの次のレコードがロードされるようにロジックを記述します。レコードを変更するために、ボタンが押されるたびにインクリメントする変数を使用する必要があります。次のようにする：

WHEN

• 「ボタンが押された

次に

• "データ操作" "値のインクリメント" "カウンタ"
• によって"静的値" "数値" "1"
• "テーブルレコード" "ロードレコード"
• ID "静的値" "テキスト" (SKUを含む変数) + (カウンター変数) into: (レコード・プレースホルダー)

つまり、アクティブなSKUを含む変数と、オペレーターが進むにつれて一貫してカウントアップする変数が必要になります。

このアプローチは、複数の作業指示書のすべての内容を維持することを容易にします。あなたの指示が一貫したフォーマットを持っている場合、これはうまく機能しますが、あなたの指示に複数のタイプのステップがある場合、おそらく別の方法を使用したいと思うでしょう。

トリガーロジックの使用

上記のほとんどすべてのシナリオで、アプリのビルドを成功させるには、カスタムトリガーを作成する必要があります。簡単なものはすでに紹介しました：

• カウンタ変数のインクリメント
• 新しいアプリに変更する
• 別のステップグループに移動する
• バーコード番号を保存する

ここでは、上記のアプリ構築パターンのいずれかに登場する可能性のある、より高度なパターンをいくつか紹介する：

一連のIF文

工場に50の異なるアクティブなSKUがあるとしよう。それぞれのSKUには別々の作業指示がある。オペレーターを正しい指示セットに自動的に送る「ルーティングアプリ」を作りたい場合、異なるSKU番号で50個の「if」ステートメントを作成する必要があります。このすべてを1つのトリガーで行うことができます。これは、if/then文を手作業でたくさん作成する必要がありますが、誰でもトリガーをクリックして、何が起こっているかを簡単に理解することができます。

以下は、1つのif/then文の例です：

文字列の連結

文字列の連結は、単に "2つの文字列の結合 "を意味する。テーブルレコードIDは文字列なので、オペレータに正しいコンテンツを提供するために、文字列IDを使用して工夫することができます。

例えば、複数の製品ラインに共通する洗浄工程があるとします。それには5つのステップがある。複数のアプリで同じクリーニング手順を再構築するのは、メンテナンスが大変なので避けたいかもしれません。

その代わりに、「共通手順」と呼ばれるテーブルを作成し、共通工程の手順を含めることができます。そして、"Cleaning-1 "や "Cleaning-2 "のようなレコードIDを使用して、1つのプロセスに関する一連の手順を表示するとよいでしょう。

次に、トリガー・エディターで、特定のプロセスと、ステップを進めるごとにインクリメントする変数を組み合わせます。上の "表 "のセクションで、"Static Value:Text "フィールドで2つの変数を組み合わせた例を示します。

文字列の連結では、いつ停止するかわからないことがある。つまり、洗浄プロセスに5つのステップがある場合、カウンタが "6 "になったら別のステップに移る必要があります。これを実現するには、トリガーの "If "ステートメントを使って、まずステップが存在するかどうかをチェックします。

このように：

if

• "テーブル" "dynamic_work_instructions" "IDを持つレコードがある"
• "静的値" "テキスト" (ここに動的コンテンツを挿入)

SQLの使用

過去にSQLデータベースを作成した経験があれば、SQLデータベースからテキストや画像を動的にロードするSQLコネクタを作成することもできます。これにより、上記のTablesの例のように、1ステップのテンプレートを作成し、そこにデータをロードすることができます。

これは、データのロードに複雑な要件がある場合に有効です。この方法をご利用になる場合は、チューリップの担当者にご連絡ください。データベースのセットアップ方法についてアドバイスさせていただきます。

参考資料

• Tulipでデジタル作業指示書を作成する方法
• 拡張可能な作業指示書のためのチューリップ・ターミナルの使用方法

お探しのものは見つかりましたか？

community.tulip.coで質問を投稿したり、他の人が同じような質問に直面していないか確認することもできます！