ハンディターミナル導入2026｜タイ工場のRFP・PoC・受入試験

ハンディターミナル 導入をタイ工場で成功させるには、端末の型番比較より先に、対象業務、コード体系、通信断時の動作、上位システムとの取引単位、合否判定を決める必要があります。本稿では、入荷、棚入れ、ピッキング、払出、仕掛品移動、棚卸、出荷を対象に、RFP作成からPoC、FAT/SAT、展開、保守引継ぎまでを実務順に整理します。特定メーカーの性能や市場価格を並べるのではなく、自社の現場で再現できる証拠によって選ぶためのガイドです。

ハンディターミナル 導入の結論：端末ではなく業務取引を設計する

導入判断の中心は「どの端末が高性能か」ではありません。誰が、どの場所で、何を読み、どの在庫・ロット・仕掛情報を、いつ確定し、通信断や重複送信が起きたときにどう復旧するかです。RFPでは次の8項目を同じ基準で比較します。

この8項目の未決事項を残したまま購入台数を決めると、端末は届いても業務がつながりません。逆に、業務取引と合否条件が明確なら、候補端末や実装方式が違っても同じ土俵で比較できます。

ハンディターミナル 在庫管理の対象業務を先に切り出す

最初に、紙やExcelを「端末に置き換える」と表現するのをやめます。現状の記録媒体ではなく、在庫が動く事実と、その事実を承認する取引を特定します。GS1 Global Traceability Standardも、追跡対象の工程と記録すべき重要なイベントを定義するところから設計します。入荷、保管、ピッキング、梱包、出荷では、ハンディ機器と固定式の読取機器を組み合わせることがあり、識別情報とイベント情報を切り離さないことが重要です。

現状業務は正常系と例外系を分けて観察する

正常な一件だけを動画に撮って要件化すると、量産開始後に例外がアプリ外へあふれます。現場観察では、少なくとも次を採取します。

• どの帳票、ラベル、画面を見て判断しているか
• 品目、ロット、数量、保管場所、容器、作業者をいつ確定するか
• 分納、過納、欠品、代替品、ラベルなし、読取不能、混載をどう扱うか
• 開梱、詰替え、分割、統合、戻入、廃棄で追跡単位がどう変わるか
• 承認が必要な差異と、現場判断で進められる差異の境界
• 記録時刻と実際の物の移動時刻がずれる場面
• 一台を複数人・複数シフトで共有するか、個人に割り当てるか
• 手袋、片手操作、騒音、低照度、屋外、冷所、粉塵など操作条件

業務フローには、成功経路だけでなく「止める」「保留する」「責任者を呼ぶ」「後で同期する」を明記します。端末アプリが判断を代替する範囲と、人が判断する範囲を混ぜないことが、誤出荷や帳簿在庫のずれを防ぐ第一歩です。

KPIは導入効果ではなく受入可能な測定方法にする

「作業を効率化する」「入力ミスを減らす」だけでは受入できません。基準値は自社で実測し、PoCと本番受入で同じ定義を使います。たとえば、入荷一明細の処理時間なら、開始・終了条件、保留時間を含むか、再作業をどう数えるかを固定します。誤り率なら、スキャン拒否、誤品目確定、数量訂正、上位連携失敗を別々に記録します。

比較式の例は次です。数値は案件ごとの観測値を入れ、一般的な改善率を仮定しません。

処理時間改善 = 現状中央値 − 新方式中央値

完全処理率 = 追加の手書き・再入力・管理者修正なしで完了した取引数 ÷ 全試行取引数

在庫整合率 = 物理確認とシステム残高が定義した単位で一致した件数 ÷ 確認件数

平均だけでなく、品種、エリア、シフト、経験度、例外種別で分けます。改善を約束値にする場合は、測定サンプル、除外条件、データ所有者もRFPへ入れます。

バーコード管理 システムはコード体系とマスターが土台

ハンディターミナルはラベルに書かれた情報を読み取れますが、その文字列が何を意味するか、現物と一意に結び付くか、期限切れや廃止コードをどう扱うかはシステム設計です。ハードウェアを決める前に「何を識別するか」を決めます。

識別対象とイベントを分ける

品目コードだけでは、ロット別在庫や容器単位の移動は追えません。案件に応じて、次の識別対象を整理します。

• 品目・製品・原材料
• ロット・バッチ・シリアル
• 保管場所、棚、ゾーン、ステージング場所
• パレット、箱、通い容器など物流単位
• 発注、入荷、製造指図、払出、出荷など業務文書
• 作業者、設備、検査状態、品質保留状態

そのうえで、「受領した」「棚へ置いた」「別の容器へ分けた」「製造へ払い出した」「数えた」「出荷した」というイベントと結び付けます。識別子とイベントが別管理になり、後から表計算で結合する運用では、監査証跡と即時性が失われます。

GS1仕様は採用範囲と年版を明記する

GS1 General Specificationsは、GS1識別キーとバーコードの利用方法を定めています。GS1の変更通知ページでは、2026年1月の公表版が現在の公開ベースラインとして示され、その後の変更は次版候補として扱われています。候補変更をすでに必須規則であるかのようにRFPへ書かないことが重要です。

GS1を採用する場合も、どの識別キー、アプリケーション識別子、シンボルを、サプライヤーラベルと社内ラベルのどちらへ適用するかを決めます。既存ERPの内部品目コードをそのままGS1キーと呼ばない、可変長項目の区切りを実装任せにしない、日付・ロット・数量の形式をサンプルで確認する、といった基本が必要です。

ラベル品質は仕様書ではなく使用環境で試す

GS1の実装ガイダンスが示すとおり、バーコードの種類、寸法、配置、品質は読取環境に依存します。テストには実際のプリンター、材質、貼付面、距離、照明、角度、曲面、汚れ、擦れ、しわ、透明包装、反射を持ち込みます。

RFPには「読み取れること」だけでなく、次を記載します。

• 対象シンボルとエンコード例
• 最小・最大ラベル寸法は実物サンプルで合意すること
• ラベル位置と向きの許容範囲
• 良品、限界品、不良品の判定見本
• 一読で確定してよいコードと、画面確認を必要とするコード
• 同一視野に複数コードがある場合の選択ルール
• 読取不能時の再発行、手入力、承認、監査記録

コードの再設計が大きい場合は、バーコードだけでなくRFIDも比較対象になります。タイ工場のRFID導入費用とPoC設計では、タグ、リーダー、設置、連携、現場試験を分けて考える方法を解説しています。両方式を流行で選ばず、対象物、読取点、必要な一括読取、金属・液体、ラベル工程、例外処理で比較します。

ハンディターミナルのRFPで実機要件を定義する

型番欄からRFPを書き始めると、現場条件が「推奨機種の仕様」に引っ張られます。先に作業シナリオを渡し、ベンダーへ適合根拠、制約、代替案を回答させます。落下性能、保護等級、電池持続時間などはメーカー公称値だけで受入れず、自社条件で確認します。本稿では普遍的な数値を置きません。

スキャナーと入力方式

1D/2D、近距離・遠距離、画面上のコード、低品質コード、複数コード選択など、必要な読取を列挙します。Zebra DataWedgeは一つの実装例で、内蔵イメージャー、カメラ、Bluetoothや接続スキャナー、1D/2Dデコーダー設定を扱います。ただし特定ベンダーの方式を全端末共通の要件とはしません。

RFPでは、読取開始ボタンの位置、左右どちらの手で使うか、連続読取、二重読取抑止、音・振動・画面による成功通知、誤読時の取消しを確認します。手袋の種類や現場騒音も実物で評価します。画面タッチだけでなく、物理キーやスキャントリガーを使う工程では、作業姿勢と疲労も観察対象です。

電池・充電・交換をシフト運用として設計する

電池の公称容量や連続時間だけでは運用可否を判断できません。画面輝度、スキャン頻度、Wi-Fi再接続、バックグラウンド同期、温度、経年、シフト間充電が消費に影響します。PoCでは実業務に近い負荷で開始時と終了時の残量を記録し、充電機会、予備電池、交換方法、充電器の配置、故障時の代替を確認します。

充電設備には、必要コンセント、電源保護、棚の寸法、端末番号、清掃、持出管理も含めます。「台数＝同時利用台数」ではありません。故障、点検、充電、教育、予備を在庫モデルとして設計し、購入台数の根拠を残します。

耐環境性は証明書と現場試験を分ける

落下、粉塵、水、温度、薬品、静電気、手袋、屋外光など、対象現場の危険を一覧化します。メーカー試験の条件と現場条件が一致するかを確認し、証明書で評価できる項目と現場で再現する項目を分けます。意図的な破壊試験を行う場合は、試験方法、供試品、合否、所有権、安全措置を契約前に合意します。

Wi-Fiとオフラインファーストを一つの要件として扱う

「工場にWi-Fiがある」と「ハンディ業務が途切れず成立する」は別です。アクセスポイントの位置、チャネル、干渉、移動経路、ローミング、認証、再接続、上位APIの応答を実際の端末とアプリで確かめます。同時に、通信断を障害として完全に排除するのではなく、どの業務を継続し、どの業務を止めるかを設計します。

サイトサーベイは作業経路で実施する

平面図上のカバレッジだけでなく、棚間、ドック、冷所、屋外、搬送路、エレベーター、金属設備周辺を歩きます。稼働中の干渉や端末の保持方向も含め、接続先、切替、遅延、再送、切断を記録します。特定の電波強度だけを万能な合否値にせず、業務取引が完了するかと合わせて判定します。

ゲストWi-Fiや事務所用ネットワークへ無条件に接続させるのではなく、専用の認証、セグメンテーション、アクセス制御、ログ、証明書更新を検討します。NIST SP 800-82 Rev.3は、OTにセキュリティ対策を適用する際、性能、信頼性、安全を保つ必要があるとしています。これは製品認証ではなく、ネットワーク分離、最小権限、管理されたID、ログ、制御された無線アクセスを設計原則として使うための参考です。

オフライン時の「できる・できない」を取引別に決める

Androidのオフラインファースト設計ガイダンスでは、重要機能を不安定な接続下でも利用可能にし、ローカルの信頼できるデータ源、書込みキュー、競合解決を設計します。ただし、オフライン書込みが自動的に安全になるわけではありません。

たとえば、既知の作業指示に対するスキャン記録はキューへ保存できても、最新在庫の引当、品質保留解除、重複し得るシリアル登録はオンライン確認が必要かもしれません。取引ごとに次を決めます。

• オフラインで参照できるマスターと有効期限
• オフラインで作成できる取引と上限・権限
• 画面に表示する最終同期時刻と未送信件数
• 再接続時の送信順序、再試行、バックオフ
• 同じ物を別端末で処理した場合の競合ルール
• サーバー拒否時に物理在庫をどう保留・戻入するか
• 端末紛失・故障時に未送信データをどう扱うか
• キューの暗号化、削除、監査ログ、サポート手順

ハンディターミナル 業務システムの連携方式を選ぶ

スキャン文字列をキーボード入力として既存画面へ流す方式は、短期間の検証や単純入力に向く場合があります。一方、取引状態、複数項目、エラー制御、監査証跡が必要なら、アプリがスキャンイベントを明示的に受け取り、APIで業務取引を送る設計が適します。方式を優劣で決めず、リスクと保守責任で選びます。

キーストローク入力と明示的連携を比較する

キーストローク方式では、カーソルが正しい欄にあるか、接頭・接尾文字、改行、画面遷移、文字コード、別アプリへの誤入力を確認します。既存Web画面を使える利点がある一方、入力元の識別や生データ、スキャン設定をアプリが十分に管理できないことがあります。

明示的なIntentやSDK/API連携では、読み取ったデータ、シンボル種別、状態をプログラムで処理できます。Zebra DataWedgeのIntent OutputはAndroidアプリへ明示的Intentでデータを渡す実装例で、パッケージ指定や任意のアプリ署名確認により誤配信リスクを下げる機能があります。生データはキーストローク出力と同じではなく、バージョン依存の詳細は対象端末の現行資料と実機で検証します。

API取引は冪等性と監査証跡を必須にする

無線再接続やタイムアウトでは、「サーバーは受け取ったが端末は応答を受け取れなかった」状態が起こります。再送のたびに在庫を二重移動しないため、端末側で取引IDを発行し、同じIDの再送をサーバーが同じ結果として扱えるようにします。

最低限、次の項目を取引ログへ残します。

• 取引ID、端末ID、利用者ID
• 業務種別、対象品目・ロット・容器・場所
• 端末での発生時刻、サーバー受信時刻、確定時刻
• アプリ版、マスター版、オンライン／オフライン状態
• 初回送信、再送回数、応答コード、最終結果
• 取消し、訂正、承認者、訂正理由

監査ログは個人を責めるためではなく、物の動きとシステム状態を再現するために使います。ログ保持期間、検索権限、時刻同期、個人情報の扱いも運用設計に含めます。

WMS・ERP・MESの正本を一項目ずつ決める

在庫残高はERP、ロケーション在庫はWMS、製造実績はMES、端末は未送信キューを持つ、という構成では、どの項目をどのシステムが正本とするかが重要です。品目名、単位換算、ロット状態、棚、指図状態、ユーザー権限について、作成・変更・参照・廃止の責任表を作ります。

WMS全体の投資範囲を検討中なら、タイ工場向けWMS導入費用の分解ガイドも参照してください。端末費だけを切り出すと、マスター整備、API、Wi-Fi、教育、棚ラベル、運用移行が見えません。WMS導入とハンディ導入を別契約にする場合も、統合テストと障害切分けの責任を一つの表で合意します。

専用端末・EMM・セキュリティを運用設計に含める

Androidの専用端末は、業務目的で完全管理されるデバイスです。許可したアプリだけを使うキオスク運用、シフト共有、管理されたプロビジョニング、QRコード登録などが可能です。Androidの資料はEMMを利用する場合のエンドツーエンドテストを明示的に推奨しています。

配布から廃棄までのライフサイクルをRFPへ書く

初期登録、Wi-Fi・証明書配布、アプリ配信、設定変更、OS更新、紛失時ロック、交換、初期化、廃棄を一連の運用にします。Android Management APIのプロビジョニング資料では、会社所有の業務専用端末を完全管理し、一つまたは少数の許可アプリへ制限する選択肢が示されています。ゼロタッチ、QRコード、NFC、DPC識別子などの登録方法がありますが、利用条件や適格なEMM構成を確認し、すべての企業が直接利用できると仮定しません。

端末台帳には、資産番号、シリアル、利用部署、割当、アプリ版、OS、電池・修理履歴、紛失状態、廃棄証跡を持たせます。共有端末では、利用者のログイン・ログアウト、シフト交代、未送信キュー、個人設定の残存をテストします。

最小権限とサポート用アクセスを分ける

作業者、班長、倉庫管理者、IT管理者、保守ベンダーに同じ権限を与えません。手入力、差異承認、マスター同期、ログ閲覧、遠隔操作、アプリ更新を分離します。サポート用の一時権限には承認、期限、記録を持たせ、共有パスワードを恒久利用しない設計にします。

PoCで「読めた」から「業務が成立した」まで確認する

PoCは端末のデモではなく、最も不確実な仮説を小さく潰す工程です。候補端末を一斉に試すこと自体が目的ではありません。ラベル品質、Wi-Fi移動、オフライン取引、手袋操作、上位API、共有シフトなど、失敗した場合に設計や予算が変わる項目を優先します。

PoC計画書に固定する項目

• 検証仮説と、合格・条件付き合格・不合格の定義
• 対象業務、場所、シフト、利用者層、端末・アプリ版
• 実ラベル、実データに近い匿名化データ、例外サンプル
• 開始条件、試験手順、測定器、記録様式
• 通信断、電池低下、重複送信、サーバー停止など異常投入
• セキュリティと安全上、実環境で実施できない試験の代替
• 不具合の重大度、再試験、設計変更、費用負担
• PoC環境から本番へ引き継ぐものと廃棄するもの

PoC結果は「好評だった」という感想で閉じず、試験ID、入力、期待結果、実結果、証拠、判定、残課題、担当、期限を残します。利用者の自由記述は重要ですが、測定結果と分けて管理します。

QRコード 在庫管理で試すべき例外

QRコードを使う場合も、2Dだから情報を多く入れられるという理由だけで採用しません。ラベルに何を保持し、何をサーバー照会するかを決めます。長いデータ、誤った区切り、旧版、同一品の複数コード、画面表示コード、損傷、反射、曲面、コピー、権限外のコードを試します。外部取引先のコードと社内QRが併存するなら、アプリが誤ったコードを受理しない識別規則が必要です。

FAT・SAT・展開判定を段階化する

FATでは、供給者の管理環境で端末、アプリ、サーバー連携、設定、文書を確認します。SATでは、タイ工場の実Wi-Fi、実ラベル、実利用者、実上位システム、実運用時間帯で統合を確認します。両方の試験名が同じでも、前提と証拠を分けます。

FATで確認する内容

• 要件追跡表がRFP、設計、試験へつながっているか
• 対象シンボル、データ形式、入力制御、例外画面
• API正常系、タイムアウト、再送、重複、拒否、取消し
• ローカルキュー、再起動、電池切れ、競合解決
• 権限、キオスク、アプリ配信、ログ、遠隔支援
• インストール手順、設定バックアップ、復元、交換端末の準備
• 操作手順、管理手順、障害切分け表、既知制約

SATで確認する内容

• 棚、ドック、製造現場を移動した通信とローミング
• 実ラベルの良品・限界品・不良品と複数コード
• シフト交代、共有端末、充電、予備機交換
• ERP/WMS/MESの実マスターと業務締め処理
• 同時利用、ピーク取引、プリンター、時刻同期
• ネットワーク断、上位停止、復旧後照合
• 現場教育後に利用者が手順だけで業務を完了できるか
• IT、業務、供給者が障害を再現し責任箇所を切り分けられるか

パイロットから全体展開へ進む出口条件

一拠点・一工程の成功だけで全数展開を自動承認しません。未解決の重大不具合がないこと、データ照合が完了したこと、サポート体制が稼働したこと、交換機とバックアップが準備されたこと、教育対象が完了したこと、旧運用への戻し条件が定義されたことを出口条件にします。

段階展開では、拠点、工程、シフトごとに責任者、凍結期間、移行在庫、初日支援、判定会議を設定します。アプリやマスターを展開中に変更する場合は、どの集団がどの版を使っているかを追跡します。

ベンダー中立のハンディターミナル導入TCO

見積比較は端末単価だけで行いません。評価期間を決め、初期費、運用費、変更費、停止影響、終了費を同じ前提に正規化します。市場価格や一般的な回収期間は案件条件で大きく変わるため、本稿では断定しません。

TCO = 初期取得・設計費 + 展開費 + 評価期間中の運用保守費 + 変更・拡張費 + 停止影響 + 終了・移行費 − 残存価値

初期費に含める項目

• 端末、スキャナー、電池、充電器、保護具、予備機
• ラベルプリンター、消耗材、棚・場所ラベルの整備
• Wi-Fi調査、増設、認証、証明書、ネットワーク設定
• 業務分析、コード・マスター設計、UI、開発、API
• EMM・キオスク・アプリ配布の初期構築
• PoC、FAT、SAT、移行、教育、文書化、プロジェクト管理

継続費とリスク費に含める項目

• ソフトウェア、EMM、サポート、クラウド等の利用費
• 電池・端末交換、修理、清掃、予備品、輸送
• OS・アプリ・API更新、セキュリティ対応、証明書更新
• 新品目、新ラベル、新拠点、新工程への変更
• 問合せ受付、一次切分け、現地・遠隔支援、教育更新
• 故障・通信断・連携障害・誤処理による停止や再作業
• 契約終了時のデータ抽出、端末初期化、後継者への移行

停止影響は、一つの平均金額に隠さず、業務別に式を置きます。

停止影響 = 停止時間 × 影響を受ける人員・設備の時間費 + 代替作業費 + 再入力・照合費 + 出荷・生産影響

発生確率を使う場合は、推測値と実績値を区別し、感度分析を行います。安価な構成、基準構成、障害・交換が増えた構成など同じ式で比較すれば、どの前提が意思決定を左右するか見えます。

RFPと受入試験のチェックリスト

RFPに添付する成果物

1. 対象範囲と業務フロー、正常・例外一覧
2. 識別対象、コード辞書、ラベル実物、マスター責任表
3. 現場環境、操作条件、Wi-Fi・セキュリティ条件
4. 画面、入力、権限、オフライン、監査ログ要求
5. WMS/ERP/MES連携、取引ID、冪等性、エラー処理
6. PoC、FAT、SAT、パイロット、展開の合否条件
7. EMM、更新、紛失、交換、バックアップ、廃棄の運用
8. 教育、文書、保証、SLA、ソース・設定・利用権
9. 見積内訳、前提、除外、変更単価、TCO入力表

提案評価で要求する証拠

提案書の「対応可能」だけでは点を付けません。実機デモ、構成図、試験記録、設定例、障害対応フロー、責任者、前提条件を証拠にします。必須条件を満たさない提案を価格点で救済しないこと、未回答をゼロではなくリスクとして記録すること、評価者が採点理由を残すことが重要です。

よくある質問

ハンディターミナル 導入では何から始めますか？

端末選定ではなく、入荷、棚入れ、払出、棚卸、出荷など対象取引と例外の観察から始めます。誰が何を読み、どのデータを確定し、どのシステムへ渡すかを業務フローと識別辞書にします。その後、実ラベル、実Wi-Fi、実作業姿勢を使うPoCで候補を比較します。

ハンディターミナル 在庫管理はオフラインでも使えますか？

設計すれば一部の業務を継続できますが、すべての取引を安全に確定できるとは限りません。ローカルの信頼できるデータ、キュー、再送、取引ID、競合解決、サーバー拒否後の物理処理が必要です。最新在庫の引当や品質状態変更などはオンライン必須にする判断もあります。

バーコード管理 システムとQRコード 在庫管理はどう選びますか？

情報量だけでなく、読取距離、ラベル寸法、既存取引先コード、複数コード、印刷品質、貼付面、必要なデータ標準で選びます。実ラベルの良品・限界品・不良品を用意し、対象端末と現場条件で試験してください。QRコードでも、古いマスターや複製コードを防ぐ業務設計は別途必要です。

ハンディターミナル 業務システムは既存ERP画面へ入力するだけでよいですか？

単純でオンライン前提の入力ならキーストローク方式が適する場合があります。重複防止、オフライン、複数項目、監査証跡、厳格なエラー処理が必要なら、明示的なスキャン連携とAPI取引を検討します。方式ごとに誤入力、タイムアウト、再送、別アプリへの配信を試験します。

ハンディターミナル導入費用はどう比較しますか？

端末単価に加え、充電・予備、ラベル、Wi-Fi、アプリ、API、EMM、PoC、展開、教育、更新、修理、停止、終了移行を同じ評価期間で比較します。市場価格を当てはめるより、必要台数と作業量、契約単価を候補各社に同じ入力表で回答させる方が有効です。

FATとSATでは何が違いますか？

FATは供給者の管理環境で機能、連携、オフライン、セキュリティ、文書を確認します。SATはタイ工場の実Wi-Fi、実ラベル、実利用者、実上位システム、シフト運用で統合を確認します。試験項目が重なっても、前提、証拠、合否、残課題を分けます。

まとめ：買う前に「読み取り後の取引」を受け入れ可能にする

ハンディターミナル 導入の成否は、端末スペックではなく、識別、イベント、通信断、連携、権限、運用、受入試験を一つの業務設計としてつなげられるかで決まります。実ラベルと実作業でPoCを行い、FATで機能と異常処理、SATでタイ工場の統合を確認し、取引IDと監査ログで再現可能にしてください。費用は端末単価ではなく、ラベル、Wi-Fi、アプリ、WMS/ERP/MES連携、EMM、展開、保守、停止、移行を含むTCOで比較します。

TOMAS TECHでは、端末メーカーを決める前の業務整理、コード・マスター設計、Wi-Fi／オフライン要件、RFP、PoC、WMS・ERP連携、FAT/SATまで、タイ工場の条件に合わせて検討できます。まだ対象工程や必要台数が固まっていない段階でも、お問い合わせください。

一次情報

• GS1 General Specifications: https://www.gs1.org/standards/barcodes-epcrfid-id-keys/gs1-general-specifications
• GS1 General Specifications Change Notifications: https://ref.gs1.org/standards/genspecs/gscn/
• GS1 Global Traceability Standard: https://www.gs1.org/standards/gs1-global-traceability-standard/current-standard
• GS1, 10 steps to barcode your product: https://www.gs1.org/standards/barcodes/10-steps-to-barcode-your-product/english
• Android Developers, Dedicated devices overview: https://developer.android.com/work/dpc/dedicated-devices
• Android Developers, Build an offline-first app: https://developer.android.com/topic/architecture/data-layer/offline-first
• Android Management API, Provision a device: https://developers.google.com/android/management/provision-device
• Zebra DataWedge, Barcode Input: https://techdocs.zebra.com/datawedge/latest/guide/input/barcode/
• Zebra DataWedge, Intent Output: https://techdocs.zebra.com/datawedge/latest/guide/output/intent/
• NIST SP 800-82 Rev. 3: https://www.nist.gov/publications/guide-operational-technology-ot-security