- 印刷する
チューリップ共通データモデル
のテーブルを使用して製造工程間を接続し、ユースケースを解決するためにアプリケーションを組み合わせることができます。 Tulip Common Data Model{target=_blank
}.依存関係に依存する従来のデータモデルとは異なり、Tulipのコンポーザブルな共通データモデルでは、ケースバイケースで時間をかけてテーブルを追加できます。
テーブルを通じて、アプリは相互に作用する。あるステーションでアプリを使用しているオペレーターが、別のステーションでアプリを使用しているオペレーターにシグナルを送る方法は、テーブル内のステータス更新です。例えば、マネージャーがあるアプリで作業指示を作成し、オペレーターが別のアプリやアプリのセットでその作業指示を実行する。
ベストプラクティス
:::(Info) (前提条件)データモデルを構成するテーブルに入る前に、チューリップにデータを格納するためのベストプラクティスを理解することが重要です:
つまり、テーブルは物理的な工場や現場をできるだけ厳密に反映する必要があります。履歴データは完成記録に限定し、テーブルはマスターデータや完成記録や外部レコードからの重複データを保存するために使用しないようにします。
理想的には、テーブルは以下のものだけを表す:
- 物理的な成果物
- 運用アーティファクト
これらのテーブルには、アプリによって定期的に更新される Status フィールドが常に含まれる。
| タイプ|説明|例|---|-|-|-|-|-|-|-|-|-|-|物理的な人工物|これは、現場で物理的に触れることができる、具体的なものである。| インベントリーアイテム、設備、資産|オペレーショナル・アーティファクト|これは、オペレーションに関連してよく見られる、一意に識別される無形の要素です。これらはしばしば印刷された旅行者やチケットとして見られる。| 欠陥イベント、作業指示
しかし、ベストプラクティスを破ることを検討する必要がある場合もある。より高度な状況では、できるだけ控えめに、以下の2つのセカンダリテーブルタイプを使用する必要があるかもしれません:
- ログ
- 参照
これらのテーブルのデータは静的なもので、更新されない可能性が高い(そのため、これらのタイプのデータは、完了レコードまたは元の外部システムに保持することが望ましい)。
Secondary table types do not fit within a Digital Twin model and should only be considered by advanced users.これらのテーブルタイプは、ソリューション設計プロセスを経て、他のすべてのオプションを使い尽くした場合にのみ含めるようにしてください。セカンダリテーブルタイプは、アプリソリューションの基盤としては決して使用しないでください:
| タイプ | 説明 | 例 | --- | --- | リファレンス | これは、本番で何かを調べ、定義することができる情報です。これらはERPのような外部システムにあることが多い。| 材料定義、部品表|ログ|これはアプリケーション間で共有される元帳です。アプリケーション間で共有され、テーブル・クエリ、集計、チューリップ・テーブルの変更可能性にアクセスできることを除けば、これは完了レコードの概念に似ています。| ステーション活動履歴、検査記録
主なテーブルタイプ
物理的成果物
物理的アーティファクト(Physical Artifacts)とは、オペレーション中に使用または生成される有形オブジェクトまたはコンポーネントです。
Physical Artifact の状態は変更または更新され、この変更はレコードに反映される(ステータスの変更など)。
以下の表の説明は、その名前よりも優先される。テーブルの説明の本質に沿ったものであれば、運用に合わせてテーブル名を自由に調整してください。
在庫項目
場所とアイテムごとの在庫を保持します。
ステーション
ショップフロアのすべてのステーションを表示します。
ユニット
ユニークな物理的ロット、シリアル番号、バッチを保存するために使用されます。
設備と資産
再利用可能な機器または装置で、部品表には含まれないが、手順に必要な場合があり、校正が必要な場合がある。
ロケーション
製造現場における物理的な場所。ピック・ツー・ライトのためのライトキットの位置と関連付けることができる。
オペレーション・アーティファクト
オペレーション・アーティファクトとは、オペレーションを可能にする、またはサポートする非物理的要素またはコンポーネント。これらはしばしば印刷された旅行者やチケットとして見られる。
オペレーション・アーティファクトは、記録に対してオペレーションが実行されることを意味する(ステータスの変更など)。
以下の表の説明は、名前よりも優先されます。テーブルの説明のエッセンスと一致している限り、テーブルの名前は運用に合うように自由に調整してください。
材料リクエスト
部門間の特定品目の材料補充リクエストを保持します。
作業オーダー
業務の生産要件。注文から生成され、注文を満たすために生産される特定の材料の要求を表します。
不良品
欠陥の追跡。各ラインは、単一の材料または偏差の観察に関連する固有の欠陥です。ラインは複数の数量を持つことができます。
アクション
フォローアップが必要なイベントを保持します。
かんばんカード
セカンダリ(上級者向け)テーブルタイプ
以下のセカンダリテーブルタイプは、デジタルツインモデルには適合しません。リファレンステーブルやログテーブルは、ソリューションデザインプロセスを経て、他のすべてのオプションを使い尽くした場合にのみ含めるべきです。これらのテーブルは、アプリソリューションの基盤として使用すべきではありません。
ログ
Logs are a secondary table type within the Tulip Common Data Modelデジタルツインモデルに適合しないため、上級ユーザーのみが考慮すべきです。ログテーブルは、ソリューションデザインプロセスを経て、他のすべてのオプションを使い果たしてから含めるべきです。ログテーブルは、決してアプリソリューションの基盤としては使用しないでください。 ::: 履歴データは伝統的にアプリの完了を経由して追跡され、完了レコードに保存されるため、ログテーブルを使用する必要があるのは以下の場合のみです。
履歴レコード * トレーサビリティ
メモとコメント
ユーザーは、作業指示書、シフト、またはその他のプロセス成果物に添付されるメモを保存できます。
ステーション活動履歴
ステーションごとの生産アウトプットとステータスの履歴を、時間ごとにグループ化して保存します。マシン・アクティビティ・テーブルと同様の機能と目的。
系譜レコード
各レコードは親子関係にある。子はシリアル化または非シリアル化されたサブアセンブリまたは個々の部品である。
検査結果
検査対象の材料に関連する手順ステップの結果を保存します。これらは合格/不合格の結果、またはユーザーからの入力を必要とするプロセスステップ中に行われた測定結果です。
参照
References are a secondary table type within the Tulip Common Data Modelリファレンステーブルは、デジタルツインモデルに適合しないため、上級ユーザーのみが考慮する必要があります。リファレンステーブルは、ソリューションデザインプロセスを経て、他のすべてのオプションを使い尽くした場合にのみ含めるべきです。リファレンステーブルは、アプリソリューションの基盤としては絶対に使用しないでください:
可能な限り、データは元のソース(ERPなど)からHTTPコネクタを介して直接リアルタイムで取得する必要があります。一時的にERPとの接続を確立している間、参照テーブルを使用する必要があるかもしれません。
ソリューションが成熟し、システムがより統合され、緊密に結合されるようになるにつれて、あなたのアプローチは時間の経過とともに進化するでしょう。
材料定義
製造、購入、組み立てられたすべての品目の定義。品目とその具体的な特性について説明します。
部品表
このテーブルは通常、このデータをリアルタイムで渡すことのできる記録システムとの統合の代わりに使用される。このテーブルは、親アイテムの指定された製品の部品表と手順を保持します。必要な構成品目と数量を工程ごとに分けて表示するために使用できます。