10:47 Un radar de détection de drones doit être accepté en fonction de l'ensemble de cibles approuvé par l'acheteur, de la géométrie du site et du flux de travail de réponse, et non uniquement sur une démonstration contrôlée par le fournisseur. Le plan de test doit distinguer la fonction du produit, la couverture du projet et la performance opérationnelle de bout en bout, puis conserver suffisamment de données pour que le résultat puisse être examiné de manière indépendante. Utilisez la source Guide d'achat de radars de détection de drones et de surveillance à basse altitude pour la ligne de base des achats approuvée et le Guide RFI/RFP pour le calendrier de réponse et de preuves du fournisseur contrôlé.
Comment tester sur le terrain et accepter un système de radar de détection de drones
Avant le premier essai, figez la configuration exacte du site que le résultat représentera : coordonnées et hauteurs des capteurs installés, versions des logiciels et algorithmes, zones actives, cartes d’encombrement, étalonnage des caméras, chemin réseau, source temporelle et plan de couverture approuvé. Les preuves d’acceptation sont invalides si ces entrées changent sans un enregistrement contrôlé.
La ligne de base du test doit également identifier chaque hypothèse provisoire héritée de la conception, y compris les obstacles temporaires, les travaux civils incomplets, les limitations dues aux conditions météorologiques, les interfaces indisponibles et les secteurs qui ne peuvent pas encore être exercés. Classez chaque élément comme une limitation acceptée, une précondition de test ou un défaut nécessitant une résolution.
Enregistrez un hash de configuration ou une exportation contrôlée pour les réglages du radar, de la caméra et de la plateforme lorsque l’équipement le permet. Au minimum, conservez les fichiers de configuration datés et des captures d’écran afin qu’un nouveau test ultérieur puisse reproduire l’état accepté.
| Stage | Décision primaire | Emplacement typique |
| Preuve de concept | L'architecture proposée peut-elle traiter la menace et le concept d'interface? | Site du fournisseur ou du représentant |
| Essai sur le terrain avant attribution | La configuration proposée peut-elle fonctionner sous les objectifs et conditions pertinents pour l'acheteur? | Site de l'acheteur ou site du représentant technique |
| Test d'acceptation en usine | La configuration contractuelle a-t-elle été construite, configurée et documentée correctement? | Installation du fournisseur |
| Test d'acceptation sur site | Le système installé répond-il aux exigences du projet contracté? | Site de déploiement |
| Période d'acceptation opérationnelle | La performance est-elle durable lors du fonctionnement normal? | Site de déploiement sur une période convenue |
Une preuve de concept réussie ne remplace pas SAT, et une démonstration sur le site du fournisseur ne prouve pas la couverture de l’acheteur. Indiquez quelle décision chaque étape soutient et quels risques non résolus restent après celle-ci.
Un essai sur le terrain devrait tester le système proposé en fonction des conditions d'exploitation de l'acheteur. Une démonstration sur un site contrôlé par le fournisseur peut confirmer la fonction de base, mais elle ne prouve pas la couverture ni la performance en termes de fausses alertes sur le site de déploiement.
Le plan de test devrait définir la cible, l'itinéraire, l'altitude, la vitesse, la direction d'approche, la météo, les réglages du système, la vérité terrain, les critères de succès, les données à enregistrer et la procédure de retest. Il devrait également faire la distinction entre une preuve de concept, un test d'acceptation en usine, un test d'acceptation sur site et une période d'acceptation opérationnelle.
| Scénario de test | Ce qu'il faut mesurer | Exemple de sortie de contrat |
| Approche nominale | Détection, initiation de suivi et suivi stable sur un itinéraire représentatif | Rapport sur la portée et la continuité avec comparaison aux données réelles |
| Flotter / mouvement lent | Comportement à basse vitesse et maintien sur la voie | Durée maximale de chute autorisée et comportement de reacquisition |
| Chemins qui se croisent et se séparent | Sensibilité à l'aspect et continuité de la piste | Suivre l'exhaustivité à travers les secteurs définis |
| Cibles multiples simultanées | Séparation des pistes, stabilité de l'identité et capacité | Aucun échange de piste inacceptable ni piste en double |
| Activité liée aux oiseaux et à l'environnement | Faux alertes, sortie de classification et charge de travail de l'opérateur | Performance mesurée sur une période d'observation convenue |
| EO/IR inclina vers le repère | Conversion de coordonnées, latence et acquisition de cible | La cible apparaît dans le champ de vision et le temps convenus de la caméra |
| Communications dégradées | Mise en mémoire tampon, basculement, alarme et comportement de récupération | Récupération définie sans perte de données silencieuse |
| Défaillance du capteur ou du serveur | Surveillance de la santé, redondance et journalisation des événements | Défaillance détectée, signalée et traitée conformément au SLA |
| Nuit / conditions défavorables | Performance dans des conditions de visibilité et météorologiques pertinentes | Limitations enregistrées et plage de fonctionnement acceptée |
Ne copiez pas de seuils génériques dans le contrat sans les valider par rapport au site et au flux de réponse. Une exigence telle que « cible dans le cadre en cinq secondes » peut être appropriée pour une géométrie de caméra et trop lente ou irréaliste pour une autre. Le critère d’acceptation doit être dérivé du besoin opérationnel et démontré avec l’équipement proposé.
Toutes les données de test doivent être conservées dans un format convenu. L'acheteur devrait recevoir les journaux d'événements, les pistes, les horodatages, les enregistrements de référence, les paramètres de configuration et un rapport de test signé. Une déclaration de réussite/échec sans preuves sous-jacentes n'est pas suffisante pour un projet de surveillance complexe.
Comment tester sur le terrain et accepter un système de radar de détection de drones
Le calendrier cible doit identifier la classe représentative de multirotor ou d'aile fixe, les dimensions physiques ou la base RCS convenue, l'état utile, la vitesse, l'altitude, l'itinéraire, la direction d'approche et le mode de fonctionnement. Inclure les cas radiaux, tangentiels, croisés, en retrait, en stationnaire et à faible encombrement ou à fort encombrement lorsque cela est pertinent opérationnellement.
La vérité terrain peut être établie par des points de passage relevés, la télémétrie GNSS, la vidéo synchronisée, des équipements de suivi indépendants ou une combinaison de méthodes. Définir l'horloge de référence, le décalage autorisé et l'incertitude avant les tests. Conserver la source de la vérité terrain, les horodatages bruts et les preuves de synchronisation; autrement, la portée de détection, la latence, l'erreur de signalement et la précision du suivi ne peuvent pas être évaluées de manière défendable.
| Scène de spectacle | Quoi enregistrer |
| Détection initiale | Premier temps et portée de détection valides selon la règle de confirmation convenue |
| Initiation de piste | Heure et position auxquelles une piste provisoire ou confirmée est créée |
| Suivi stable | Continuité de suivi, pertes autorisées, reacquisition et taux de mise à jour |
| Classification | Étiquette de classe, confiance, latence, gestion des inconnus et cas d'erreur |
| Génération d'alarme | Logique de zone, délai d'alarme, suppression et reconnaissance par l'opérateur |
| Exportation de données | Horodatage, identité, coordonnées, fréquence de mise à jour et réception par une plateforme externe |
Un bref retour faible ne devrait pas être considéré comme un suivi stable. Définissez la règle de confirmation, l'écart permis, le comportement de reacquisition et le seuil de qualité de suivi avant de tester.
La performance en cas de fausse alarme doit être observée avec l'activité normale du site présente: oiseaux, véhicules, végétation, machines, vagues, précipitations et aéronefs autorisés le cas échéant. Enregistrez la durée de l'observation, les zones actives, les réglages de sensibilité, la version du logiciel et les interventions de l'opérateur. Un pourcentage de classification en laboratoire ne remplace pas la performance face aux fausses alertes sur le site.
Le test d'intégration devrait mesurer la chaîne complète depuis la création de la piste radar jusqu'à la présentation de la cible dans le plate-forme de caméra et de commande. Vérifiez les cadres de coordonnées, le terrain ou les hypothèses sur la hauteur, les horodatages, la latence du réseau, mouvement PTU et l'installation, l'étalonnage du pointage, la sélection du champ de vision, le transfert, la cartographie des événements et l'identité de la piste. Une déclaration indiquant que le radar peut exporter des coordonnées n'est pas un résultat d'acceptation. Utilisez le architecture de fusion radar-vision comme la référence du système adjacent pour l'interface et la portée de repérage.
| Point de contrôle d'intégration | Preuve d'acceptation |
| Suivre le message | Message capturé avec des champs d'identité, de temps, de coordonnées et de qualité |
| Conversion de coordonnées | Enregistrement d'erreur de point connu ou de trajet représentatif |
| Commande de caméra | Résultat de la cible dans le cadre à portée et champ de vision définis |
| Vidéo et métadonnées | Enregistrement synchronisé avec association d'événements et de pistes |
| Gestion des échecs | Comportement documenté pendant une interruption du capteur, du réseau ou du service |
| Plateforme externe | Alarme, suivi et reconnaissance visibles dans le client opérationnel proposé |
Le plan devrait indiquer combien d'essais sont nécessaires, si les résultats sont évalués par essai ou sur une série définie, et ce qui constitue un essai invalide. Définissez les droits de retest en cas d'interruption météorologique, de déviation de la cible, de défaillance de l'équipement et d'anomalie observée par l'acheteur. Un scénario échoué ne doit pas être remplacé par un itinéraire plus facile ou un réglage différent du système sans un enregistrement de modification contrôlé.
Si le fournisseur ajuste les filtres de désordre, les seuils de classification ou les zones d'alarme pendant l'essai, enregistrez le changement, l'heure et la raison. La configuration finale acceptée doit être exportée et protégée comme référence pour les futurs FAT, SAT ou la surveillance opérationnelle.
Comment tester sur le terrain et accepter un système de radar de détection de drones
Les étapes de paiement doivent être liées à des livrables contrôlés tels que des documents de conception approuvés, la réussite du FAT, l'équipement livré, l'installation terminée, le passage du SAT et la clôture des éléments de la liste de contrôle convenus. Évitez les étapes basées uniquement sur l'expédition ou la mise sous tension lorsque l'objectif du contrat est une capacité de surveillance intégrée.
Un bref SAT peut ne pas révéler l'encombrement saisonnier, les pannes réseau intermittentes, la charge de travail de l'opérateur ou la dérive des performances. Pour les sites à forte valeur, définissez une période d'acceptation opérationnelle avec la configuration approuvée verrouillée, l'entretien de routine enregistré et les statistiques représentatives des alarmes examinées. La période devrait identifier les actions correctives autorisées, le contrôle des changements logiciels, le calcul du temps de disponibilité, le traitement des défauts non résolus et les preuves requises pour la clôture finale.
L'acceptation opérationnelle ne doit pas introduire silencieusement de nouvelles exigences. Elle vérifie la livraison soutenue de la capacité contractée et clôt les défauts qui n'ont pas pu être évalués pendant la fenêtre de test planifiée.
Un test sur le terrain défendable est reproductible, spécifique à la cible, conscient du site et étayé par des preuves. Il sépare la détection initiale du suivi stable, mesure les fausses alertes et l'intégration, enregistre la vérité terrestre synchronisée et conserve les données sous-jacentes. La décision d'acceptation qui en résulte peut ensuite être intégrée dans le contrat sans se fier au langage du prospectus ou à une démonstration non documentée.
Non. Les tests sur le site du fournisseur peuvent confirmer le fonctionnement de base, mais la couverture du projet, l'encombrement et l'intégration doivent être vérifiés sur le site de déploiement ou à un emplacement techniquement représentatif.
La période devrait représenter l’activité et le risque normaux du site. Définissez la durée et les conditions de fonctionnement dans le plan de test plutôt que d’utiliser une démonstration courte non documentée.
Pistes brutes, horodatages, vérité terrain, vidéo, journaux d'événements, paramètres de configuration, versions du logiciel, relevés environnementaux et rapport de test signé.
Avant l'attribution du contrat. Une définition tardive crée des différends concernant les objectifs, les itinéraires, les paramètres, les conditions environnementales et les règles de réussite/échec.
Nous vous répondrons sous 24 heures. Pour les cas urgents, veuillez ajouter WhatsApp/WeChat : 86 86 13361376820, ou appeler directement le 86 86 13361376820.
*Nous respectons votre confidentialité et toutes les informations sont protégées.
Nous n'utiliserons vos informations que pour répondre à votre demande et n'enverrons jamais d'e-mails non sollicités ni de messages promotionnels.
