Résumé exécutif
La coopération Radar OEM et ODM devrait convertir les exigences du projet d’un client en une configuration de produit contrôlée, documentée et reproductible. Cela peut inclure le marquage, l’intégration mécanique, l’adaptation de l’alimentation et du montage, le travail sur l’interface de données, l’intégration C2 ou EO/IR, la configuration logicielle, la documentation, les tests et le support du cycle de vie. Cela ne devrait pas signifier changer chaque paramètre sans contrôle d’ingénierie.
La valeur de Midradar pour les intégrateurs de systèmes repose sur la combinaison de produits radar, de l'expérience en intégration EO/IR et PTU, des fonctions logicielles MR2000 C2 et de l'examen des interfaces au niveau du projet. La portée finale dépend du modèle sélectionné, de la destination, de l'utilisation finale, des exigences de performance, de l'effort de développement et du plan de vérification.

Solutions Radar OEM et ODM : des exigences du projet à la livraison répétable
Questions clés auxquelles ce guide répond
- Quelle est la différence entre radar OEM, ODM et l'intégration de systèmes ?
- Quels éléments matériels, d'interface, logiciels et de documentation peuvent être personnalisés ?
- Comment une plateforme radar standard devrait-elle être choisie avant le début des modifications techniques ?
- Comment les prototypes, les lignes de base de configuration et les demandes de changement sont-ils contrôlés ?
- Quels termes concernant la propriété intellectuelle, les coûts de développement non récurrents, la quantité minimale de commande, la garantie et le cycle de vie doivent être convenus ?
Applicabilité et limite de personnalisation
Ce guide s'applique aux intégrateurs système et aux partenaires régionaux qui ont besoin d'une configuration radar reproductible dérivée d'une plateforme Midradar existante. L'OEM modifie généralement le branding, la documentation, l'emballage ou certaines interfaces externes tout en conservant le design du produit de base. L'ODM peut impliquer une adaptation plus large des aspects mécaniques, électriques, logiciels ou des flux de travail. Aucun de ces termes ne signifie que chaque changement demandé est techniquement, commercialement ou légalement disponible. Le projet doit séparer les éléments configurables des éléments de conception protégés, des fonctions régulées et des modifications qui nécessiteraient un nouveau programme de vérification ou de certification.
1. OEM, ODM et l'intégration de systèmes sont différents
Le fabricant d'équipement d'origine (OEM) commence normalement avec une plateforme de produit établie et adapte le branding, la documentation, les interfaces ou les options de configuration approuvées. Le fabricant de conception originale (ODM) peut inclure des modifications plus profondes de conception mécanique, électronique ou logicielle pour une exigence client définie. L'intégration système connecte le radar aux caméras, aux plateformes de C2, aux réseaux et aux flux de travail opérationnels.
Un projet peut utiliser les trois modèles, mais le contrat devrait les séparer. Les changements de marque, l'adaptation de l'interface, la conception d'un nouvel boîtier et la livraison complète du système impliquent des efforts d'ingénierie, une propriété, des tests et un support différents.
Examiner Midradar capacités de la technologie radar avant de définir la limite de personnalisation.
Modèle commercial et support du cycle de vie
Un programme OEM/ODM durable nécessite plus que l'approbation du prototype. Les parties devraient définir les prévisions et hypothèses de commande minimale, les frais d'ingénierie non récurrents, la propriété des outillages, les prix des échantillons et de la production, les étapes de paiement, les délais, la garantie, les pièces de rechange, la politique de mise à jour des logiciels, la gestion de l'obsolescence et le processus de décisions de fin de vie. La propriété intellectuelle et les droits d'utilisation doivent être explicites pour la technologie Midradar standard, les adaptations financées par le client, les actifs de branding et le matériel développé conjointement.
La version de production doit référencer un ensemble approuvé de nomenclature, de plans, de version logicielle, de document d'interface et de spécification de test. Les modifications ultérieures nécessitent une évaluation des impacts et des tests de régression. Sans cette discipline, un prototype réussi peut devenir un produit de production instable dont le coût de support dépasse la valeur de personnalisation initiale.
Matrice de contrôle de personnalisation
| Change Class |
Typical Examples |
Exigence de contrôle |
| Configuration à faible impact |
Marquage, étiquettes, langue, emballage et paramètres approuvés |
Examen des documents et enregistrement de la configuration |
| Adaptation de l'interface |
Connecteur, mappage de messages, champs UI ou pilote tiers |
CIM, test d'intégration et contrôle de version |
| Design change |
Boîtier, puissance, montage, changement thermique ou environnemental |
Révision d'ingénierie, prototype et vérification |
| Développement de nouvelle plateforme |
Changement majeur de RF, antenne, forme d'onde, traitement ou architecture |
Plan de développement séparé, risques, conformité et base de référence d'acceptation |
2. Une matrice de personnalisation contrôlée
La personnalisation devrait être divisée en catégories. La personnalisation commerciale peut inclure les marques privées, le nom des modèles, l'emballage et les documents destinés aux clients. La personnalisation mécanique peut inclure les supports, les connecteurs, le routage des câbles, les radômes, les kits pour véhicules ou trépieds et les traitements environnementaux. La personnalisation électrique peut inclure l'entrée d'alimentation approuvée, le brochage des connecteurs et les faisceaux système. La personnalisation logicielle peut inclure le branding de l'interface utilisateur, les rôles des utilisateurs, les cartes, les zones d'alarme, les flux de travail et les rapports. La personnalisation de l'interface peut inclure le mappage des messages, l'adaptation des champs de données, la conversion de coordonnées et le contrôle des dispositifs.
Chaque changement demandé doit être classé comme standard, configurable, modification d'ingénierie ou non pris en charge. Cela protège le calendrier et l'intégrité du produit et donne aux deux parties une base claire pour les coûts et l'acceptation.
Utilisez le catalogue radar actuel identifier une plateforme standard avant de demander des modifications. Lorsque le projet nécessite également une définition formelle des exigences avant la sélection du fournisseur, se référer à la guide d'achat de radar de détection de drones.
3. Flux de développement
Un projet OEM/ODM discipliné suit normalement sept étapes : clarification des exigences, revue de faisabilité, base de configuration, prototype ou échantillon d'ingénierie, vérification, livraison pilote et production contrôlée. La phase des exigences doit définir les performances cibles, l'environnement, l'installation, les interfaces, la cybersécurité, la documentation, la conformité et l'acceptation.
L'examen de faisabilité identifie ce qui peut utiliser une plateforme existante et ce qui nécessite un développement. La base de référence enregistre le matériel sélectionné, la version du logiciel, les dessins, les documents d'interface et les responsabilités. La vérification du prototype doit couvrir à la fois l'élément modifié et son effet sur le système complet. La livraison pilote confirme la répétabilité de la fabrication avant une production plus importante.

Solutions Radar OEM et ODM : des exigences du projet à la livraison répétable
4. Adaptation de l'interface et du logiciel
L'adaptation de l'interface est souvent plus précieuse pour un intégrateur qu'un changement esthétique. Un projet peut nécessiter que les données de suivi radar soient mappées sur une plateforme client, dans un système de coordonnées spécifié, avec des horodatages synchronisés, des informations sur l'état des appareils, le contrôle EO/IR, des journaux d'événements ou un flux de travail d'alarme défini.
Midradar peut évaluer l'intégration spécifique au projet en utilisant des données radar basées sur Ethernet, les fonctions MR2000 C2 et le couplage radar-vers-EO/IR. Les API exactes, SDK, versions de protocole et champs de données doivent être confirmés lors de l'examen technique. Lorsqu'une norme telle qu'ASTERIX, SAPIENT, ONVIF ou une autre interface industrielle est demandée, la catégorie, le profil, la version et les tests d'acceptation requis doivent être indiqués avant de prétendre à la compatibilité. Utiliser le guide de sélection pan-tilt lorsque le système personnalisé inclut un EO/IR guidé par radar.
5. Documentation, propriété intellectuelle et contrôle des modifications
Le projet devrait définir la propriété et l'utilisation autorisée des dessins, du micrologiciel, du code source, des documents d'interface, des outils de test, de l'image de marque du client et des travaux développés conjointement. La plupart des projets ne nécessitent pas le transfert de toute la propriété intellectuelle sous-jacente. Ils requièrent une documentation suffisante pour l'intégration, l'exploitation, la maintenance et le support futur convenu.
Les changements doivent être contrôlés par des exigences numérotées, des dessins et logiciels versionnés, des registres de déviation et des points d'approbation. Le client doit savoir quelle configuration est proposée, testée, livrée et prise en charge. Cela est particulièrement important lorsque des marques privées ou des numéros de modèle client masquent la référence technique originale.
6. Vérification et préparation à la production
La vérification doit être dérivée de la personnalisation. Les modifications mécaniques peuvent nécessiter des vérifications de vibration, d'étanchéité, de corrosion, thermique ou d'installation. Les modifications électriques peuvent nécessiter des tests de puissance, CEM et de protection. Les modifications de l'interface nécessitent une validation des messages, le comportement de reconnexion, le minutage, la coordination et les tests de défaillance. Les modifications logicielles nécessitent des tests fonctionnels, de permissions, de journalisation, de récupération et de mise à niveau.
La préparation à la production inclut les dessins approuvés, les nomenclatures, les images logicielles, les règles de numérotation des séries, les plans d'inspection, les enregistrements de test, l'emballage, les pièces de rechange et l'autorité de délivrance. Sans ces contrôles, un prototype ODM peut fonctionner une fois mais échouer à devenir un produit reproductible.

Solutions Radar OEM et ODM : des exigences du projet à la livraison répétable
7. Informations requises de la part du partenaire
Pour lancer une évaluation OEM/ODM, fournissez la demande, les exigences cibles et de performance, la quantité et le calendrier, la destination et l'utilisation finale, le concept d'installation, les conditions environnementales, l'alimentation et le réseau, interfaces requises, équipements C2 ou EO/IR existants, champ de marque, langue de la documentation, acceptance method et modèle de support attendu.
Un ensemble complet de données d'entrée permet à Midradar de séparer la configuration disponible, le travail d'ingénierie, les risques techniques et les hypothèses commerciales avant le début du développement.
Conclusion et appel à l'action
Le partenariat OEM/ODM le plus solide combine une plateforme produit stable avec un contrôle transparent des changements d'ingénierie. Il offre à l'intégrateur suffisamment de flexibilité pour répondre au projet sans créer un produit unique non pris en charge.
Midradar peut examiner les exigences d'intégration des radars, C2, EO/IR et mécaniques et préparer une matrice de personnalisation préliminaire, une répartition des responsabilités, un plan de développement et un plan de vérification. La capacité finale reste soumise à la faisabilité technique, à la conformité et à un référentiel de projet approuvé.
FAQ
Midradar peut-il fournir des produits radar en marque blanche ?
Les exigences en matière de marque de distributeur et de branding peuvent être évaluées dans le cadre d'un périmètre OEM, sous réserve d'un examen du modèle, du marché, de la documentation, de la conformité et des aspects commerciaux.
ODM signifie-t-il que le client reçoit le code source ?
Pas automatiquement. La portée de la propriété intellectuelle et de la livraison du logiciel doit être définie contractuellement. De nombreux projets nécessitent une documentation d'interface et un support de configuration plutôt qu'un transfert complet du code source.
Quel est le premier livrable OEM/ODM ?
Une matrice des exigences et des personnalisations qui sépare les articles standard, configurables, modifiés par l'ingénierie et non pris en charge.
Quels articles sont normalement adaptés à la personnalisation OEM ?
Les éléments typiques à examiner incluent le branding, la couleur du boîtier, le montage, l'alimentation, les connecteurs, les champs d'interface sélectionnés, les étiquettes de l'interface utilisateur, la documentation et l'emballage. La disponibilité dépend de la plateforme et de l'effort de validation.
Comment les modifications sont-elles contrôlées après l'approbation du prototype ?
Geler une ligne de base de configuration approuvée. Les changements ultérieurs doivent utiliser une demande formelle, une évaluation de l'impact, des enregistrements mis à jour, des tests de régression et une approbation renouvelée avant la mise en production.