Az Astute DDS az Astute Systems teljes körű DEF-STAN 23-009 általános járműarchitektúra (GVA) megoldásának középpontjában álló adatelosztó köztes szoftver. Az érzékelőktől a képernyőkig egyetlen egységes platform köti össze a katonai jármű összes alrendszerét.

A hagyományos építészet problémája

A hagyományos járműrendszerek pont-pont kapcsolatokat használnak. Új alrendszer hozzáadásakor minden olyan rendszert módosítani kell, amellyel kommunikál. Ez a következőket hozza létre:

• ❌ Drága integráció – Minden új komponenshez egyedi kódolás szükséges
• ❌ Törékeny rendszerek — Egyetlen meghibásodás is átterjedhet az egész hálózatra
• ❌ Beszállítóhoz kötöttség – A saját fejlesztésű protokollok egyetlen beszállítóhoz kötik Önt
• ❌ Lassú frissítések – Egyetlen alrendszer megváltoztatása mindent újratesztelést jelent.

A közzététel/feliratkozás megoldás

A DDS közzétételi/feliratkozási architektúrájával az alrendszerek egyszerűen elnevezett témakörökbe teszik közzé az adatokat. Bármely rendszer, amelynek szüksége van az adatokra, feliratkozik a témára. Nincsenek pont-pont kapcsolatok. Nincs egyéni integrációs kód.

Üzleti előny	Hogyan jelenik meg a Pub/Sub?
💰 Alacsonyabb integrációs költségek	Új alrendszerek hozzáadása a meglévők módosítása nélkül
🔧 Könnyebb karbantartás	Az alkatrészek önálló cseréje vagy frissítése
🛡️ Nagyobb ellenálló képesség	A rendszerek akkor is működnek, ha mások meghibásodnak
🏭 Több szállító szabadsága	Különböző beszállítók berendezéseinek keverése egyetlen adatbuszon
⏱️ Gyorsabb piacra jutási idő	A szabványos interfészek kevesebb egyedi fejlesztést jelentenek

Egyetlen forrás a teljes GVA-veremhez

Az Astute Systems az egyetlen szállító, amely teljes, integrált szoftvercsomagot kínál a GVA-kompatibilis katonai járművekhez:

Összetevő	Mit csinál
bohém	SysML modellek megtekintése és validálása, interfészdefiníciók generálása
LDMX	Kategóriájában a legjobb földadatmodell-szerkesztő és -validátor az LDM v10.0.0-hoz
ToolX	Automatizált kódgenerálás, build integráció és telepítési eszközök
Éles DDS	Kapcsolja össze az összes alrendszert valós idejű, biztonságos adatelosztással
Földadat-modell v10.0.0	Előre elkészített GVA-kompatibilis adattípusok minden járműtartományhoz
Éles HMI	A DEF-STAN 23-009 szabvány követelményeinek megfelelő személyzeti kijelző szoftver

A Full Stack előnyei

Haszon	Hatás
🎯 Egyetlen felelősségi pont	Egy szerződés, egy támogató csapat, egy integrációs partner
📋 Bizonyított megfelelőség	Előzetesen validálva a DEF-STAN 23-009 követelményei szerint
🔄 Zökkenőmentes frissítések	Bármelyik komponenst fejlesztheted anélkül, hogy a többit tönkretennéd
💰 Kiszámítható költségek	Nincsenek meglepetésszerű integrációs díjak vagy licencelési nehézségek
⏱️ Gyorsabb kiszállítás	Működő szoftverrel kezdj, ne üres keretrendszerekkel

Beszerzési szempontok

Tényező	Éles DDS	RTI Connect	CiklonDDS	OpenDDS	Gyors DDS
Engedélymodell	Rugalmas lehetőségek	Ülésenkénti reklámfilm	Eclipse EPL 2.0	LGPL	Apache 2.0
Licencköltség	Versenyképes	$$$ telepítésenként	Ingyenes	Ingyenes	Ingyenes
Támogatási modell	Ausztrál szállítói szerződés	Globális vállalat	Eclipse Alapítvány	OCI reklám	eProsima reklám
Ausztráliai támogatás	✅ Igen	❌ Amerikai székhelyű	❌ Nem	❌ Amerikai székhelyű	❌ Spanyolországi székhelyű
GVA előintegráció	✅ Beépített	❌ Egyedi munka	❌ Barkácsolás	❌ Barkácsolás	❌ Barkácsolás
Teljes Stack elérhető	✅ Egyetlen forrás: HMI + LDM + DDS + Eszközök	❌ Csak köztes szoftver	❌ Csak köztes szoftver	❌ Csak köztes szoftver	❌ Csak köztes szoftver
SysML eszközök	✅ Bohemian + LDMX + ToolX	❌ Nincs	❌ Nincs	❌ Nincs	❌ Nincs
Exportellenőrzés	Ausztrál joghatóság	Az amerikai ITAR-megfontolások	EU	MINKET	EU

Műszaki jellemzők összehasonlítása

Jellemző	Éles DDS	RTI Connect	CiklonDDS	OpenDDS	Gyors DDS
DDSI-RTPS 2.5	✅ Teljes	✅ Teljes	✅ Teljes	✅ Teljes	✅ Teljes
DDS biztonság 1.1	✅ Teljes	✅ Teljes	⚠️ Részleges	✅ Teljes	✅ Teljes
X-típusok 1.3	✅ Teljes	✅ Teljes	⚠️ Részleges	⚠️ Részleges	⚠️ Részleges
Dinamikus adat API	✅ Teljes	✅ Teljes	❌ Nincs	⚠️ Alapvető	⚠️ Alapvető
TypeLookup szolgáltatás	✅ Teljes	✅ Teljes	❌ Nincs	❌ Nincs	⚠️ Részleges
Tartalomszűrés	✅ Teljes	✅ Teljes	✅ Teljes	✅ Teljes	✅ Teljes
Megosztott memória-átvitel	✅ Teljes	✅ Teljes	✅ Teljes	❌ Nincs	✅ Teljes
TCP-átvitel	✅ Teljes	✅ Teljes	✅ Teljes	✅ Teljes	✅ Teljes
Nulla másolás	✅ Támogatott	✅ Támogatott	✅ Támogatott	❌ Nincs	✅ Támogatott

Szabványoknak való megfelelés

Standard	Éles DDS	RTI Connect	CiklonDDS	OpenDDS	Gyors DDS
OMG DDS 1.4	✅	✅	✅	✅	✅
OMG DDSI-RTPS 2.5	✅	✅	✅	✅	✅
OMG DDS-XTypes 1.3	✅	✅	⚠️	⚠️	⚠️
OMG DDS biztonság 1.1	✅	✅	⚠️	✅	✅
OMG IDL 4.2	✅	✅	✅	✅	✅
DEF-STAN 23-009 (GVA)	✅	❌	❌	❌	❌
Földadat-modell v10.0.0	✅	❌	❌	❌	❌

Nyelvi és platformtámogatás

Képesség	Éles DDS	RTI Connect	CiklonDDS	OpenDDS	Gyors DDS
C++	C++20	C++11	C99 burkoló	C++11	C++11
C	C++-n keresztül	✅ Natív	✅ Natív	❌	✅ Natív
Piton	✅	✅	✅	✅	✅
Rozsda	✅	❌	✅	❌	❌
Linux	✅	✅	✅	✅	✅
Ablakok	✅	✅	✅	✅	✅
VxWorks	Ütemterv	✅	⚠️	✅	⚠️
Beágyazott/RTOS	✅ Úgy tervezték, hogy	✅ Mikrováltozat	⚠️	⚠️	⚠️
Statikus linkelés	✅ Egyetlen könyvtár	⚠️	⚠️ Megosztott könyvtárak	⚠️ Megosztott könyvtárak	⚠️ Megosztott könyvtárak

Miért nyer az Astute DDS?

az RTI Connexttel szemben	vs. CycloneDDS	az OpenDDS-szel szemben	vs. gyors DDS
Rugalmas licencelési lehetőségek	Teljes X-Types támogatás	Teljes dinamikus adat API	Ausztráliai székhelyű támogatás
Ausztrál szállító, nincsenek ITAR aggályok	Beépített biztonság	TypeLookup szolgáltatás	Teljes GVA-megfelelőség
Egyetlen forrásból származó teljes GVA-verem	Kategóriájában legjobb LDMX + ToolX	Kategóriájában legjobb LDMX + ToolX	Egyszerűbb telepítés
LDM v10.0.0 tartalmazza	Kereskedelmi támogatás	Ausztrál joghatóság	Teljes X-típusok

„Az Astute rendszer használatával 40%-kal csökkentettük a GVA integrációs időkeretét. Azzal, hogy egyetlen szállító felelt a köztes szoftverekért, a HMI-ért és az adatmodellért, kiküszöböltük a korábbi programokat sújtó ujjal mutogatást.”

— Programmenedzser, az Egyesült Királyság védelmi minisztere

---

Garantált interoperabilitás

Az Astute DDS teljes mértékben kompatibilis az összes főbb DDS-implementációval. Járműve zökkenőmentesen kommunikálhat a következőkkel:

Nincs szállítóhoz kötöttség. Ha egy partnerrendszer eltérő DDS-implementációt használ, az Astute DDS módosítás nélkül csatlakozik.

---

Védelmi szabványoknak való megfelelés

Katonai követelményeknek megfelelően készült

Standard	Állapot
DEF-STAN 23-009	✅ Teljes körű GVA-megfelelőség
Földadat-modell v10.0.0	✅ Teljes domain típusok
NATO STANAG	✅ Interoperabilitásra kész
Kiberbiztonsági alapismeretek	✅ Biztonsági tanúsítvánnyal rendelkezik

Megbízható biztonság

• 🔐 Titkosított kommunikáció — Minden adat védett az átvitel során
• 🎫 Tanúsítványalapú hitelesítés — Csak jogosult rendszerek csatlakoznak
• 📋 Hozzáférés-vezérlési szabályzatok — Határozza meg, hogy kik tehetnek közzé vagy iratkozhatnak fel az egyes témákra
• 📝 Teljes körű auditnaplózás — A biztonsági felülvizsgálatok teljes körű naplózása

---

Bizonyított gyártásban

Több programban telepítve

Az Astute DDS-t Ausztrália, az Egyesült Királyság és a szövetséges országok védelmi miniszterei bízzák meg:

Domain	Alkalmazások
🎖️ Páncélozott járművek	Legénységi kijelzők, szenzorfúzió, fegyverintegráció
🤖 Robotika és autonóm rendszerek	Pilóta nélküli földi járművek, robotplatformok, autonóm navigáció
🛡️ Ellen-UAS (CUAS)	Drónészlelő, követő és legyőző rendszerek
✈️ Földi irányítóállomások	UAV irányítás és vezérlés, szenzorok tápellátása
🚢 Haditengerészeti rendszerek	Hídkijelzők, kárelhárítás, navigáció
🏭 Képzés és szimuláció	Szintetikus környezetek, utólagos értékelés, kiértékelés

---

🎬 Demó igénylése

Tekintse meg az Astute DDS-t és a teljes GVA-csomagot működés közben. Tudjon meg többet a csomagunkról, vagy kérjen bemutatót most.

A fejlesztők által leggyakrabban feltett kérdések az Astute DDS bevezetésekor.

1. Mi az Astute DDS?

Az Astute DDS az OMG Data Distribution Service C++20 implementációja.
(DDS) DCPS API, DDSI-RTPS 2.5 vezetékes protokoll, DDS-XTypes 1.3 típusú rendszer,
DDS-Security 1.1/1.2 bővítmények és IDL 4.2. Statikus verzióként kerül leszállításra.
libastutedds.a könyvtár (plusz C, Python és Rust kötések) és a következővel érkezik:
az astutedds-inspect diagnosztikai grafikus felhasználói felület és egy interoperábilis Shapes demó.

2. Hogyan tudok témát közzétenni és feliratkozni rá?

Hozz létre egy DomainParticipant , egy Topic , majd egy DataWriter (közzétevői oldal)
vagy DataReader (előfizetői oldal):

 using namespace astutedds::dcps;

auto dpf = DomainParticipantFactory::get_instance();
auto dp  = dpf->create_participant(0, PARTICIPANT_QOS_DEFAULT, nullptr, 0);
auto topic = dp->create_topic("Hello", "HelloMsg", TOPIC_QOS_DEFAULT, nullptr, 0);

// Publisher
auto pub    = dp->create_publisher(PUBLISHER_QOS_DEFAULT, nullptr, 0);
auto writer = pub->create_datawriter(topic, DATAWRITER_QOS_DEFAULT, nullptr, 0);
writer->write(sample, HANDLE_NIL);

// Subscriber
auto sub    = dp->create_subscriber(SUBSCRIBER_QOS_DEFAULT, nullptr, 0);
auto reader = sub->create_datareader(topic, DATAREADER_QOS_DEFAULT, nullptr, 0);

Lásd: Első lépések › Első jelentkezés .

3. Mi a különbség read() és take() között?

• read() függvény visszaadja a mintákat, de **az olvasó gyorsítótárában hagyja** azokat, így a későbbi hívások (vagy ugyanazon előfizető más olvasói) újra beolvashatják azokat.
• take() függvény mintákat ad vissza, majd **eltávolítja** azokat a gyorsítótárból.

Használd read() függvényt, ha a téma a megvizsgálni kívánt megosztott állapotot jelöli.
ismételten; használd take() , ha a téma a kívánt eseményeket jelöli
pontosan egyszer fogyasztani.

4. Miért nem kapnak korábbi mintákat a később csatlakozó előfizetők?

Alapértelmezés szerint DURABILITY VOLATILE , tehát a feliratkozó előtt írt minták
a párosított elemek nem kerülnek kézbesítésre. A később csatlakozóknak korábbi minták kézbesítése érdekében
konfigurálja az írót és a megfelelő olvasókat TRANSIENT_LOCAL használatával
tartósság (ami RELIABLE megbízhatóságot is igényel):

 DataWriterQos qos;
writer->get_qos(qos);
qos.durability().kind   = TRANSIENT_LOCAL_DURABILITY_QOS;
qos.reliability().kind  = RELIABLE_RELIABILITY_QOS;
writer->set_qos(qos);

Az író újraindításai közötti megmaradáshoz használja a
Perzisztencia Szolgálat vagy az TRANSIENT / PERSISTENT
tartóssági típusok.

5. Mit csinál a RELIABILITY QoS?

• BEST_EFFORT (alapértelmezett számos beépített témakörnél): a vezetéken elveszett minták nem kerülnek újraküldésre. Legalacsonyabb többletterhelés.
• RELIABLE : az író nyomon követi az egyes egyező olvasóktól érkező visszaigazolásokat ( ACKNACK / szívverés), és újraküldi a hiányzó sorszámokat, amíg a
  az olvasó utoléri, vagy megtelik a történelem.

A megbízhatóság írónként/olvasónként változó, és kompatibilisnek kell lennie: a BEST_EFFORT
Az olvasó felveheti a versenyt egy RELIABLE íróval, de fordítva ez nem így van.

6. Mit csinál a DURABILITY QoS?

DURABILITY szabályozza, hogy a mintákat megőrzik-e az olvasók számára történő kézbesítéshez.

amelyek a minta megírása után csatlakoznak:

Fajta	Későn csatlakozóknak is elérhető?
VOLATILE	Nem
TRANSIENT_LOCAL	Igen, amíg az író él
TRANSIENT	Igen, az író teljes élettartama alatt (a Persistence Service-en keresztül)
PERSISTENT	Igen, a folyamatok újraindítása között (lemezen)

7. Mi a különbség HISTORY és DURABILITY között?

HISTORY ( KEEP_LAST(depth) vagy KEEP_ALL ) szabályozza, hogy hány minta kerüljön

az író/olvasó gyorsítótára bármikor tárolható. DURABILITY szabályozza, hogy a
Az író később illeszkedő mintákat kínál az olvasóknak. Együtt dolgoznak, de
különböző problémák megoldása: KEEP_ALL önmagában nem tesz elérhetővé mintákat
a későn csatlakozóknak.

8. Hogyan adhatok meg egy domain azonosítót?

Adja át a domain azonosítót első argumentumként create_participant függvénynek:

 auto dp = DomainParticipantFactory::get_instance()
              ->create_participant(42, PARTICIPANT_QOS_DEFAULT, nullptr, 0);

A különböző domaineken lévő résztvevők nem kommunikálnak egymással. A DDSI-RTPS port
7400 + 250 * domain_id képlet határozza meg a használt alap UDP portokat
felfedezés.

9. Miért nem találják meg egymást a kiadóm és az előfizetőm?

Gyakori okok:

1. Különböző domainazonosítók – mindkét résztvevőnek ugyanazt az azonosítót kell használnia.
2. Multicast blokkolva — Az SPDP UDP multicastot használ 239.255.0.1 címen, a következő címen:
   alapértelmezett. Ellenőrizd a gazdagép tűzfalát, és kapcsold be az IGMP snoopingot.
3. Hibás hálózati interfész — több otthonú gazdagépeken ASTUTEDDS_NETWORK_INTERFACE= beállítás szükséges ASTUTEDDS_NETWORK_INTERFACE= vagy konfigurálja a felderítési JSON/XML profilban (lásd: JSON felderítési konfiguráció ).
4. Nem kompatibilis QoS – lásd a 15. kérdést.
5. Különböző átviteli protokollok – ellenőrizze, hogy mindkét fél UDPv4-et (vagy mindkettőt UDPv6-ot) használ-e.
   TCP, SHM).

Nyomkövetési naplózás engedélyezése ASTUTEDDS_LOG_LEVEL=trace és csomag vizsgálata
rögzítés astutedds-inspect paranccsal.

10. Milyen IDL funkciók támogatottak?

A mellékelt astutedds-idl fordító az OMG IDL 4.2-t valósítja meg, beleértve a következőket:

• Primitív típusok ( boolean , octet , integer típusok, int8 – uint64 , float / double / long double , char / wchar , string / wstring ).
• Struktúrák, uniók, felsorolások, bitmaszkok, typedef-ek.
• Korlátos és nem korlátos sorozatok, tömbök, leképezések.
• @key , @id , @optional , @default , @range , @min , @max , @unit , @extensibility(FINAL|APPENDABLE|MUTABLE) , @nested . (A változónevek és kommentek fordítandók, de ebben a kódrészletben ilyenek nincsenek.)
• Konstansok és module névterek.

A generált C++ alapértelmezés szerint XCDR2-t használ, opcionális XCDR1-gyel az interopcióhoz.

11. Hogyan szűrhetem a saját magam által publikált mintákat?

Két lehetőség:

1. Résztvevői szintű figyelmen kívül hagyás : hívja dp->ignore_publication(handle) függvényt
   átadja a helyi író InstanceHandle_t .
2. Szűrés az olvasó visszahívásában SampleInfo::publication_handle használatával
   és összehasonlítva az író get_instance_handle() függvényével.

Egy tartalomszűrt témakör kizárhat egy saját közzétételű kulcsmezőt is.

12. Milyen karakterek engedélyezettek a témanevekben?

A témakörök nevei tartalmazhatnak ASCII alfanumerikus karaktereket, _ és / jelet.
hierarchia elválasztó. A hossz 256 karakterre korlátozódik. Kerülje a kezdő karaktereket.
számjegyek és foglalt DDS beépített előtagok ( DCPS , dds ). A típusnevek ezt követik.
ugyanaz a szabály.

13. Hogyan észlelem, ha egy távoli író vagy olvasó elmegy?

Telepítsen egy DataReaderListener , és implementálja on_subscription_matched / függvényt.

on_liveliness_changed , vagy poll reader->get_subscription_matched_status() . A current_count_change

mező negatív, ha egy peer nem egyezik.

Az élénkséget a LIVELINESS QoS szabályozza — set

kind = AUTOMATIC_LIVELINESS_QOS lease_duration értékkel az észleléshez

néma társak egy korlátozott időn belül.

14. Hogyan kaphatok visszahívást, amikor új adatok érkeznek?

Csatoljon egy figyelőt a DATA_AVAILABLE_STATUS maszkkal:

 class MyListener : public DataReaderListener {
    void on_data_available(DataReader* reader) override {
        // call reader->take(...) here
    }
};
reader->set_listener(&listener, DATA_AVAILABLE_STATUS);

on_data_available tűzesetek mind az új minták, mind a példány életciklusa esetén

változások; mindig ellenőrizze SampleInfo::valid_data a hivatkozás törlése előtt
minta hasznos teher.

15. Mit jelent az „Inkompatibilis QoS”?

Egy író és egy olvasó csak akkor egyezik meg, ha minden kérés/felajánlott QoS teljesül.
összeegyeztethető:

Politika	Kért ≤ Felajánlott
RELIABILITY	olvasó BEST_EFFORT ≤ író RELIABLE
DURABILITY	olvasói fajta ≤ írói fajta (specifikációs sorrendben)
DEADLINE	olvasási period ≥ írói period
LATENCY_BUDGET	olvasási duration ≥ írói duration
OWNERSHIP	egyenlőnek kell lennie ( SHARED vagy EXCLUSIVE )
PARTITION	legalább egy partíciónévnek átfedésben kell lennie

Figyelje on_offered_incompatible_qos / on_requested_incompatible_qos értékeket
a pontos szabályzatazonosító futásidejű megkereséséhez.

16. Hogyan küldhetek UDP datagramnál nagyobb mintákat?

Az Astute DDS automatikusan fragmentálja a konfiguráltnál nagyobb mintákat

fragment_size (alapértelmezett 1344 bájt IPv4 esetén), és újra összerakja őket a

DDSI-RTPS DATA_FRAG alüzeneteket használó olvasó. A megbízhatósági protokoll
hiányzó töredékeket nyer vissza a teljes minta újbóli elküldése nélkül.

Nagyon nagy minták (≥ 1 MB) esetén növelje az operációs rendszer socket puffereit:

 sudo sysctl -w net.core.rmem_max=8388608
sudo sysctl -w net.core.wmem_max=8388608

és fontold meg a megosztott memóriájú átvitelre való átállást a helyi olvasók esetében.

17. Hogyan tudom beállítani, hogy melyik hálózati interfészt használjam?

Három lehetőség, fontossági sorrendben:

1. Környezeti változó: ASTUTEDDS_NETWORK_INTERFACE=eth0 .
2. JSON felderítési konfiguráció – lásd: JSON felderítési konfiguráció .
3. XML QoS profil – lásd: DDS-XML QoS profilok .

Ha nincs beállítva semmi, az Astute DDS kiválasztja az első nem visszacsatolt interfészt egy
multicast-képes cím.

18. Használhatom az Astute DDS-t hálózaton multicast nélkül?

Igen. Két alternatíva:

• Unicast SPDP partnerlista : a partner hoszt/port párok listáját adja meg a
  felderítési konfiguráció; Az Astute DDS egyedileg küld SPDP bejelentéseket minden egyes partnernek.
• TCP átvitel : a résztvevőt TCP RTPS átvitelre kapcsolja a következőhöz:
  olyan környezetek, amelyek teljesen blokkolják az UDP-t. Lásd:
  DDS Domain Router elszigetelt hálózatok keresztezéséhez.

19. Hogyan hangolhatok alacsony késleltetésre?

• Használjon RELIABLE megbízhatóságot KEEP_LAST(1) előzményekkel mindkét oldalon, így
  az újraküldések minimálisak.
• Engedélyezze a megosztott memóriájú átvitelt a közös helyen lévő résztvevők számára.
• Astute DDS szálak rögzítése CPU affinitással és valós idejű ütemezés használata
  ( SCHED_FIFO ) a közzétevő és az előfizetői folyamatokon.
• A Nagle letiltása UDP használatával (alapértelmezett).
• Növeld a socket puffereket (lásd a 16. kérdést) a löketek elnyelése érdekében.
• Állítsa LATENCY_BUDGET = 0 a kötegelt feldolgozási késleltetés letiltásához.

20. Miért látok késleltetési csúcsokat nagy minták közzétételekor?

Amikor a minták meghaladják az operációs rendszer alapértelmezett socket pufferét (gyakran 208 KB Linuxon),
a kernel eldobja a csomagokat, és a megbízható protokollnak újra kell küldenie azokat, ami
tüskék. net.core.rmem_max / net.core.wmem_max értékének emelése legalább a következőre:
A minta mérete megoldja ezt a problémát. Érdemes lehet kisebb fragment_size értékkel fragmentálni.
veszteséges hálózatokon.

21. Hogyan hidalhatok át két DDS domaint?

Használja az Astute DDS Domain Router szolgáltatást, amely két vagy több domain routert köt össze
domainek és a konfigurált témák közöttük történő továbbítása, opcionálisan
kulcs-/tartalomszűrés és QoS-fordítás. Lásd:
DDS tartományi útválasztó .

22. Milyen nyelvi kötések érhetők el?

Nyelv	Állapot	Megjegyzések
C++20	Stabil	Elsődleges API — libastutedds.a
C	Stabil	Flat C API az FFI-hez, lásd: include/astutedds/c/astutedds.h
Piton	Stabil	pybind11 kötések, CPython 3.10 – 3.13
Rozsda	Béta	astutedds láda (biztonságos csomagolás a C API felett)

23. Mely platformok és operációs rendszer verziók támogatottak?

Platform	Tesztelt verziók
Linux	Ubuntu 22.04 / 24.04, RHEL 9 / 10, AlmaLinux 9 / 10, Debian 12
Ablakok	Windows 10, Windows 11, Windows Server 2022

A Linux Python kerekek manylinux_2_28 (glibc ≥ 2.28) címkével vannak ellátva, és futnak
bármely kompatibilis disztribúción.

24. Hogyan engedélyezhetem a DDS biztonságot?

1. Identitás- (X.509) és jogosultság- (aláírt XML) összetevők kiépítése.
2. Konfigurálja a résztvevő tulajdonságának QoS-ját az Aut., Access Control és
   Kriptográfiai bővítmény tulajdonságai (CA tanúsítvány, identitás tanúsítvány/kulcs, jogosultságfájl,
   irányítási fájl).
3. Link az Astute DDS-hez, amely -DASTUTEDDS_ENABLE_SECURITY=ON beállítással készült.

A teljes körű utasításokért és a DDS Security című dokumentumban talál további információkat.
irányítási/engedélyezési sablon.

25. Hogyan őrizhetem meg az adatokat az újraindítások között?

Futtassa a Persistence Service-t a domainje mellett. Előfizet a következőkre:
konfigurált TRANSIENT / PERSISTENT témák, a mintákat egy helyi tárolóban tárolja
adatbázis (alapértelmezés szerint SQLite), és újra közzéteszi őket a késői csatlakozáshoz
előfizetők – beleértve azokat is, akik az eredeti író távozása után csatlakoznak.
Lásd: Kitartási szolgáltatás .

26. Hogyan rögzíthetem és játszhatom vissza a forgalmat?

Használja a mellékelt astutedds-record eszközt egy domain rögzítéséhez egy

.astdb fájlt, és astutedds-replay paranccsal közzéteheti azt állítható értékekkel.

időskálázás. A felvétel típusérzékeny és belsőleg XCDR2-t használ. Lásd
Felvétel és visszajátszás .

27. Hogyan fejleszthetek egy adattípust az előfizetők megszakítása nélkül?

Jelölje meg az IDL típust @extensibility(MUTABLE) (vagy APPENDABLE ) paranccsal, és
címkézd meg minden tagot @id(N) -nel. Az XCDR2 módosítható streamek lehetővé teszik:

• Új tagok hozzáadása mindkét végponthoz.
• Opcionális tagok eltávolítása.
• Tagok átrendezése.

Az X-Types hozzárendelhetőségi szabályok alapján a nem egyező tagok kimaradnak.

@extensibility(FINAL) zárolja az elrendezést, és bináris fájlok esetén kell használni.

A korábbi XCDR1 olvasókkal való kompatibilitás fontos.

28. Hogyan használhatom a tartalomszűrt témákat?

Hozz létre egy ContentFilteredTopic egy normál témából egy SQL-szerű szűrővel
kifejezést, és köss hozzá egy DataReader :

 std::vector params{"42"};
auto cft = dp->create_contentfilteredtopic(
    "HighSeverity", topic, "severity > %0", params);
auto reader = sub->create_datareader(cft, DATAREADER_QOS_DEFAULT, nullptr, 0);

A szűrő kiértékelése az író oldalon történik, amikor ez lehetséges a sávszélesség megtakarítása érdekében.

29. Hogyan konfigurálhatom a QoS-t egy XML fájlból?

XmlQosLoader használatával olvashat be egy DDS-XML profilt, és alkalmazhatja azt létrehozáskor.
entitások:

 XmlQosLoader loader;
loader.load_file("qos_profiles.xml");
auto qos = loader.get_datawriter_qos("MyLib", "ReliableProfile");
auto writer = pub->create_datawriter(topic, qos, nullptr, 0);

A sémát és a működést lásd a DDS-XML QoS profilokban .
példák.

30. Hogyan tudok interopciós vagy felderítési problémákat hibakeresni?

1. Futtassa astutedds-inspect a domainen a felfedezett információk megtekintéséhez.
   résztvevők, végpontok és egyező állapot valós időben.
2. Rögzítsd a forgalmat tcpdump -i any -w dds.pcap 'udp port 7400 or portrange 7400-7500' paranccsal, és nyisd meg a Wiresharkban — az RTPS elemzőben.
   dekódolja az SPDP, SEDP és felhasználói adatokat.
3. Nyomkövetési naplók engedélyezése: ASTUTEDDS_LOG_LEVEL=trace ASTUTEDDS_LOG_FILE=/tmp/astutedds.log .
4. Entitásazonosítók és portok ellenőrzése:
   • SPDP író/olvasó: 00:01:00:c2 / 00:01:00:c7
   • SEDP kiadvány: 00:00:03:c2 / 00:00:03:c7
   • SEDP-előfizetés: 00:00:04:c2 / 00:00:04:c7
   • Alap port: 7400 + 250 × domain_id .
5. Győződjön meg arról, hogy mindkét fél kompatibilis szállítóazonosítókat és protokollverziókat hirdet.
   (DDSI-RTPS 2.5).