Un driver temps réel pour l’acquisition de données industrielle (DAQ)
Conçu pour chaque périphérique ADDI-DATA.
ADDI-PACK est le framework unifié de drivers d’acquisition de données pour le matériel ADDI-DATA. Windows et Linux à partir d’une base de code unique, déterministe par son architecture et prêt à alimenter votre couche d’automatisation ainsi que vos systèmes MES, ERP et d’IA grâce à des API ouvertes et à des liaisons pour différents langages.
Télécharger ADDI-PACK v2026.10.1
Gratuit avec chaque périphérique ADDI-DATA.
Treize cartes. Tous les autres appareils ADDI-DATA sont en cours d’intégration.
Cinq familles de drivers, dix cartes physiques PCI et PCIe, avec une parité complète entre Windows et Linux dès le premier jour. Les autres périphériques ADDI-DATA continuent d’être fournis avec nos drivers hérités éprouvés. Toutefois, si un périphérique est essentiel à votre projet, faites-le-nous savoir. La demande des clients détermine l’ordre dans lequel nous migrons le reste du portefeuille.
| Cartes prises en charge | Windows | Linux |
|---|---|---|
| E/S numériques APCI/APCIe-1032; 1500; 1564; 2032; 2200 | APCI-1648; 1696 | APCIe-1532 | ● Disponible | ● Disponible |
| Analogique xPCIx-3001; 3002; 3003; 3009; 3010; 3016; 3021; 3110; 3116; 3120; 3121; 3126; 3200; 3300; 3501; 3521; 3600; 3660 | ● Utiliser le driver KMDF hérité | ● Utiliser le driver Linux hérité |
| E/S numériques xPCIx-1016; 1516; 2016; 040 | APCI-1532 | CPCI-1500; 1564 | ● Utiliser le driver KMDF hérité | ● Utiliser le driver Linux hérité |
| Comptage xPCIx-1710; 1711; 1712 | ● Utiliser le driver KMDF hérité | ● Utiliser le driver Linux hérité |
| Longueur xPCIx-3701-3702 | ● Utiliser le driver KMDF hérité | ● Utiliser le driver Linux hérité |
| Interface série xPCIx-7300; 7300-3; 7420; 7420-3; 7500; 7500-3; 7800 | ● Utiliser le driver KMDF hérité | ● Utiliser le driver Linux hérité |
| Contrôle d'axes APCI-8001; 8008 | ● Utiliser le driver KMDF hérité | ● Utiliser le driver Linux hérité |
Vous avez besoin que votre périphérique soit pris en charge par ADDI-PACK ?
Nous priorisons les migrations en fonction de la demande des clients. Si votre projet dépend d’un périphérique qui n’est pas encore pris en charge, faites-le-nous savoir et nous en tiendrons compte lors de la planification de la prochaine version.
Une opération. Quatre langages. Un comportement identique.
Lisez toutes les entrées numériques d’un appareil ADDI-DATA. Le même appel en C++, C, Python et C#, directement issu des exemples réels d’ADDI-PACK.
digital_input.cpp
// Production C++17
#include <addi-data/addi-pack/cpp/digital_io_interface.hpp>
using namespace addidata::addipack;
auto dev = DeviceDiscovery::getDevices().front();
auto digital = dev->digitalIo();
uint32_t value = digital->readAllDigitalInput();
std::cout << "DI: 0x" << std::hex << value;
digital_input.c
// Native C — embedded path
#include <addi-data/addi-pack/api.h>
uint8_t n = 0;
AddiDataGetNumberOfDevices(&n);
AddiDataDeviceStruct devs[8];
AddiDataGetDeviceList(devs);
uint32_t value;
AddiDataReadAllDigitalInputs(devs[0].id, &value);
printf("DI: 0x%08Xn", value);
digital_input.py
# Python 3.8+ binding
from addipack import DeviceDiscovery
device = DeviceDiscovery.get_devices()[0]
digital = device.digital_io()
value = digital.read_all_digital_input()
print(f"DI: {value:#010x}")
digital_input.cs
// C# binding
using AddiPack;
Device device = DeviceDiscovery.GetDevices()[0];
DigitalIo digital = device.DigitalIo;
uint value = digital.ReadAllDigitalInput();
Console.WriteLine($"DI: 0x{value:X8}");Pourquoi est-ce important. Chaque ligne écrite par votre équipe applicative avec ADDI-PACK reste utilisable lors du passage du banc de R&D à la ligne de production, sans réécriture, sans portage et sans nouveau cycle de validation.
C’est ce qui fait la différence entre une intégration de 6 mois et une intégration de 6 semaines.
Prêt pour la production dès aujourd’hui. Conçu pour une disponibilité industrielle maximale.
Programmes d’installation natifs : Win32/64 ; Debian/Ubuntu (.deb) ; Red Hat (.rpm)
DKMS reconstruit le module noyau à chaque mise à niveau du noyau.
La prise en charge de RTX64 figure dans la feuille de route immédiate, tandis que Linux RT, Xenomai et VxWorks sont prévus ultérieurement.
Cœur moderne en C++ avec un backend polymorphe par plateforme.
Bindings Python générés automatiquement à partir des mêmes fichiers d’en-tête.
.NET et des bindings supplémentaires figurent dans la feuille de route et partageront tous la même API sous-jacente.
Bindings Python générés automatiquement à partir des mêmes fichiers d’en-tête.
.NET et des bindings supplémentaires figurent dans la feuille de route et partageront tous la même API sous-jacente.
Compteurs matériels, temporisateurs et watchdogs ; E/S numériques synchronisées entre les cartes.
Le déclenchement en temps réel et le comptage d’événements sont gérés en mode noyau, sans gigue logicielle sur le chemin critique.
Même format de journal, même contrôle ADDI_LOG_LEVEL et mêmes outils sous Windows et Linux.
Votre équipe de maintenance apprend un seul workflow pour l’ensemble du parc.
Les API versionnées et rétrocompatibles restent fonctionnelles lors des changements de version.
Les DLL de compatibilité permettent aux applications 1.x existantes de continuer à fonctionner sans modification.
Le temps réel dur RTX64 sous Windows figure dans la feuille de route immédiate ; Linux RT (PREEMPT_RT), Xenomai et VxWorks suivront.
Une seule API pour l’ensemble de ces plateformes.
Une seule stack. Les deux noyaux. Tous les langages que votre équipe utilisera demain.
Toutes les couches situées au-dessus du noyau sont partagées. Un backend polymorphe C++17 gère les différences entre les systèmes d’exploitation afin que votre code applicatif reste identique sous Windows et Linux. Ainsi, chaque nouvelle cible RTOS, telle que RTX, Linux RT, Xenomai ou VxWorks, et chaque nouvelle liaison de langage s’intègrent au même cœur éprouvé.
Votre application
Python prototype · C++ production · LabVIEW · MATLAB · C# test bench
↓
Liaisons Python
nanobind · générées automatiquement
C# / .NET 8 bindings
API publique C / C++17
Stable · versionnée · compatible ABI
DLL de compatibilité
Les applications héritées 1.x fonctionnent sans modification
↓
ADDI-PACK Core partagé : une seule arborescence de code source pour toutes les plateformes
↓
Driver Windows KMDF
Signé · prêt pour la certification WHQL · disponible
Module noyau Linux
DKMS · reconstruction automatique · disponible
RTX / Linux RT / Xenomai
Temps réel dur · feuille de route
↓
Matériel ADDI-DATA
Un engagement public sur nos prochaines orientations.
ADDI-PACK représente un investissement à long terme. Voici ce qui est déjà à votre disposition aujourd’hui, ce sur quoi nous travaillons tout au long de l’année 2026 et la direction que prendra la plateforme d’ici 2027.
- 13 cartes PCI/PCIe réparties entre 5 familles de drivers, toutes multiplateformes Windows et Linux
- Prise en charge native de Windows 10/11 (KMDF) et Linux (DEB et RPM, DKMS)
- .NET / C# disponible depuis septembre 2026
- C, C++17, Python 3.8+, C# (win-x64 & linux-x64) /.NET 8
- Installateurs signés et testés par CI/CD
- Version RTX 64 : temps réel dur sous Windows
- Migration des cartes DAQ analogiques, de comptage et d’interface série faisant l’objet de la plus forte demande
- Prise en charge dès le premier jour des nouvelles versions Linux LTS
- Config Tools : détection et configuration des périphériques sans programmation
- Couverture complète du portefeuille ADDI-DATA, y compris MSX-E et les enregistreurs de données
- Cibles RTOS supplémentaires, notamment Linux RT, Xenomai et VxWorks
- Plugins OPC UA / MQTT / EtherCAT
- Intégration native de MSX-AIRIS pour la maintenance prédictive
Les éléments de la feuille de route indiquent des priorités et ne constituent pas des engagements contractuels. Les périodes de livraison précises sont coordonnées dans le cadre des accords conclus avec les clients et des revues produit trimestrielles.
Si vous utilisez actuellement un driver KMDF hérité, rien ne cesse de fonctionner.
Les clients existants peuvent continuer à utiliser leurs drivers actuels aussi longtemps que nécessaire. Lorsque vous serez prêt, ADDI-PACK est conçu pour être installé parallèlement à votre configuration existante, et non pour la remplacer.
Conservez votre driver existant
Tous les drivers KMDF spécifiques à chaque carte que nous avons fournis au fil des années restent disponibles, signés et pris en charge.
Aucune migration forcée.
Installez ADDI-PACK en parallèle
ADDI-PACK n’entre pas en conflit avec les installations héritées.
Utilisez les deux solutions et effectuez la validation à votre propre rythme.
Utilisez les DLL de compatibilité pour les applications existantes
Les remplacements directement compatibles de nos DLL 1.x permettent à vos applications C++, LabVIEW et Delphi existantes de fonctionner sur la nouvelle pile sans modification du code.
Adoptez la nouvelle API lorsque cela est pertinent
Nouvelles fonctionnalités, nouvelles plateformes, nouveau code : développez avec l’API unifiée.
Ancien code : conservez-le. Combinez librement les deux.
Téléchargement des drivers hérités
Pour les cartes qui ne sont pas encore intégrées à ADDI-PACK, nos drivers KMDF et Linux existants restent la solution prise en charge.
