PnP-Sensor/Aktor-System (PnPSA)

Stand der Technik

Beim Arbeiten mit Sensoren im Bereich Maschinenbau fällt mir die fehlende Digitalisierung und Interoperabilität auf! Sogar 2012 dominieren analoge Mehrkanal-Messverstärker das Bild. Häufig dient Spannung (± 10 V) zur Wiedergabe der Messgröße, neben den im Dokument Verteilerbox genannten Größen.

Hier noch einmal die aktualisierte Zusammenfassung aus jener Datei:

Warum man sich mit der vollständigen Digitalisierung so schwer tut hat mehrere Gründe:

• Extrem unterschiedliche Geschwindigkeitsanforderungen (bspw. Beschleunigungssensor vs. Thermosensor)
• Sehr unterschiedliche Genauigkeitsanforderungen (oftmals umgekehrt proportional zur Geschwindigkeit)
• Probleme mit zeitlicher Übereinstimmung
  • Langsame Sensoren mit Einzelpunkt-A/D-Wandlung: Latenzzeit
  • Schnelle Sensoren mit blockweiser A/D-Wandlung sowie autonome Datenlogger: Latenzzeit des Startzeitpunktes und Synchronität der Abtastzeitpunkte
• Verkabelung und Verkabelungsstandard
• Kosten (bspw. für die vielen A/D-Wandler)

Heutige Szenarien

Messtechnik wird heutzutage mit einem unübersichtlichen Aufwand an Kabeln, Steckern, Adaptern, Hilfsmitteln und Geräten durchgeführt, von der Software-Landschaft ganz zu schweigen.

Eine digitale Lösung muss her!

Weg mit dem Analog-Kram! Hin zu einer voll digitalen Lösung!

Meiner Meinung nach würde ich auf USB setzen. Vorteile:

• Hohe Bekanntheit, Kabel und HUBs billig verfügbar
• kein extra Messverstärker erforderlich (jeder PC hat USB, nicht jedoch CAN)
• Integriertes, klar definiertes und dennoch simples Stromversorgungskonzept, welches geräteseitig keine Weitbereichs-DC/DC-Wandler erfordert (gegenüber FireWire, PoE)
• Verfügbarkeit der Stromversorgung auch an Notebooks, Netbooks usw. (gegenüber FireWire, Ethernet)
• Relativ geringe Leistungsabgabe des PCs/Hubs (max. 2,5 W; 3.0-SuperSpeed: 4,5 W) erzwingt Energie sparende Sensoren
• Große Spanne verfügbarer Übertragungsgeschwindigkeiten für teure (schnelle) als auch billige (langsame) Sensoren (gegenüber Ethernet und FireWire)
• Keine Batterien (wie bei drahtlosen Lösungen) für langlebige und damit umweltfreundliche Sensoren ohne ständigen Pflegeaufwand (wie den turnusmäßigen Batteriewechsel oder das Aufladen von eh-zu-kurzlebigen Akkus)
• Sehr flexible Kabel (besonders bei Low-Speed; keine Schirmung erforderlich)
• Problem der gegenseitigen Synchronisation per SOF (start-of-frame, 1 kHz bzw. 8 kHz) gut lösbar und im USB-Standard vorgesehen
• „glatte“ (dekadische) Arbeitsfrequenzen (Ausgangspunkt 12 MHz) und damit Abtastfrequenzen im Gegensatz zu FireWire (24,576 MHz)
• Große Palette preiswerter Mikrocontroller macht Gesamtsensor zunehmend kostenattraktiv
• Hochwertige A/D-Wandler werden zunehmend billiger, kleiner und Energie sparender
• Die Praxis hat gezeigt, dass vielmehr bekannte Consumer-Lösungen zur Industrie gehen als umgekehrt (bspw. Ethernet, RS232)
• Host-Zentrierung ergibt klare Verhältnisse (gegenüber FireWire, Ethernet)
• PnP sowie isochrone Datenübertragung von vornherein eingebaut (gegenüber Ethernet), also echtzeitfähig
• Drahtlos-Standard WUSB vorhanden

Warum USB und eben nicht FireWire, Ethernet/EtherCat/POWERLINK oder CAN sollte sich mit dieser Aufzählung deutlich herauskristallisieren. Hohe Interoperabilität von Sensortechnik für Industrie 4.0 schließt ganz sicher USB und dessen Plug-And-Play und Selbstbeschreibung mit ein. Wie sonst sollte man einen Sensor für Losgröße 1 verwenden?

Nachteile von USB und deren Lösungen:

• Fehlender Standard für Sensoren (etwa so wie ein eingebautes, massiv erweitertes TEDS)
  • Das ist das Ziel des PnP-Sensor/Aktor-Systems!
• Keine Software verfügbar, die mehrere USB-Geräte mit zeitlicher Deckung auswertet
  • Das wird die Evaluierungssoftware zeigen, wie es geht.
• Keine verriegelbaren Steckverbinder
  • Verschiedene Anbieter haben entsprechende Steckverbinder im Programm. Das Fehlen der Verriegelung hat aber auch Vorteile. Anzumerken ist, dass Micro-B-Verbindungen Pseudoverriegelungen aufweisen, die recht sicher halten.
• Maximal 127 (Geräte + HUBs), maximal 5m/Segment
  • Sogenannte „Konzentratoren“ arbeiten wie Hubs, jedoch in einer höheren OSI-Schicht und spiegeln die Downstream-Sensortechnik auf der Upstream-Seite als Vielfach-Sensor. Für anspruchsvolle Messaufgaben sollte direkt am PC ein solcher Konzentrator angeschlossen werden.
• Fehlende Potenzialtrennung
  • Die Potenzialtrennung muss sensorseits erfolgen. Gefördert werden hierbei isolierte Sensoren, die genau deshalb keine Potenzialtrennung erfordern. Erdschleifen, gefürchtet in der Analogtechnik, sind bei USB kaum ein Problem.
  • Ein potenzialgetrennter Bus ist ohnehin Quatsch, falls der Bus an mehrere Testobjekte geht. Für die Potenzialtrennung zum Sensor eignet sich FireWire (besonders 800B) sowie PoE etwas besser, da in der Signalisierung bereits vorgesehen. Dennoch gibt es sowohl USB-Potenzialtrenner für den nachträglichen Einbau als auch die Möglichkeit der Potenzialtrennung im Sensor, heutzutage häufig gelöst über eine interne asynchron-serielle Verbindung.
• Latenz (zumindest unter Windows)
  • Der Anschluss eines Konzentrators beseitigt das Latenzproblem. Was sicherlich nicht funktioniert ist der Anschluss mehrerer Sensoren an mehrere Hostcontroller, da ihr SOF-Takt nicht gleich und nicht vorhersagbar ist. (Dafür ist eine Sync-Brücke am Konzentrator vorgesehen.)
• Verkabelung (manchmal wäre drahtlos besser)
  • Es gibt, zumindest in der Spezifikation, W-USB
• Maximale Segmentlänge: 5 m, maximale Hubtiefe: 7 (ergibt 35 m)
  • Das PnP-Sensor/Aktor-System setzt auf USB, erlaubt jedoch die Übertragung per Nicht-USB auf der Upstream-Seite von Konzentratoren. Die Synchronisation dieser Konzentratoren untereinander übernimmt entweder das gemeinsame Upstream-Protokoll (FireWire, EtherCAT) oder eine gesonderte Sync-Brücke.
• Umständliche Sync-Brücken??
  • Braucht man nur, wenn man USB verlässt!

Gibt's schon?

Sicherlich gibt es volldigitale, teilweise PnP-ähnliche Lösungen, aber jeder Hersteller kocht sein eigenes Süppchen:

• Dallas DS1820: Temperatursensor mit One-Wire-Interface
  Das Buskonzept mit den Seriennummern ist durchaus wegweisend und schön billig, aber mit USB ebenfalls gelöst
• I²C-Bus, SMBus: Kann nicht mit mehreren gleichen Chips umgehen, kein PnP
• SPI, SSC, LPC: Üblicherweise nur für Kurzstrecke (10 cm)
• RS422, DMX, RS485, CAN, Modbus, Modbus-TCP, Ethernet/IP DNP3 Profibus: Nichts mit PnP, aber schon mal bus- und echtzeitfähig
• RS232: Hat jeder PC (notfalls mit USB-RS232-Konverter), gibt's auch mit PnP(!), was ich funktionierend nur für Modems und Mäuse gesehen habe, unterstützungswürdig!, weil häufig
• Parallelport: Prinzipiell an jedem PC verfügbar (notfalls mit USB-Drucker-Konverter), unterstützt auch PnP und schnelle bidirektionale Datenübertragung: M. E. veraltet
• DDE: Kein PnP, aber etabliertes Datenübertragungsprotokoll, unterstützungswürdig!, weil häufig
• OLE: (unbekannt)
• Sockets (Ethernet, TCP/IP, WLAN): Kein PnP, kein Datenübertragungsprotokoll; der hohe Stromverbrauch von WLAN-Geräten erspart nicht das Strippenziehen!, unterstützungswürdig!, insbesondere zur Interprozesskommunikation auf dem gleichen Rechner, Linux-tauglich an Stelle von DDE
• UPnP (Ethernet): unterstützungswürdig!
• Bluetooth: hat m. W. PnP, aber kein Datenübertragungsprotokoll, unterstützungswürdig!
• ZigBee: (unbekannt), unterstützungswürdig!
• HART, WirelessHART, IEC61158: Kein PnP, viel zu langsam
• DCF77 oder ähnliche nationale Zeitnormale; GPS: Sub-Standard zur Synchronisation
• Precision Time Protocol für IP-basierte lokale Netzwerke (zumeist Ethernet, WLAN, EtherCAT)
• FireWire: Beinahe-USB?, unterstützungswürdig!
• Audio und Video (von welcher Quelle auch immer): Auch das ist Messtechnik! Man denke an Wärmebildkameras, High-Speed-Kameras für Crash-Tests … Muss irgendwie eingebunden werden.
• Hausbus (EIB, FreeBus): Kein PnP, langsam, gutes Stromversorgungskonzept, nur 2 Adern, große Reichweite
• OPC als Software-Schnittstelle für Windows, Haupteinsatzgebiet Automatisierungstechnik
• Interface A, eine Selbst-Beschreibung für Sensoren im Bereich der Chipherstellung (SEMI Group)
• PSI5 für Airbags
• Sensornetz, da scheint jede Uni ihr eigenes Süppchen zu kochen
• DIAS-Bus, VARAN
• AS-Interface
• Siemens DRIVE-CLiQ: Digitales Steckverbindersystem und Datenübertragung, bspw. für Drehwinkelgeber (Resolver) an Asynchronmotoren
• Heidenhain igrid: Datenprotokoll (Ethernet) zur Abfrage von Maschinendaten, etwa der Istposition von Achsen
• Heidenhain EnDat: SPI-Interface für Glasmaßstäbe
• IGC-Logger (Segelflug)

Welche Transportsysteme haben Synchronisation und welche nicht?

ja	nein	weiß nicht
USB FireWire EtherCAT ZigBee (via Beacon) DCF77, GPS	Ethernet serielle Schnittstelle OPC Interface A RS422, RS485 DDE	CAN Profibus ProfiNET Hausbus Bluetooth WLAN HART

Wie funktioniert das?

Synchronisation über die Datenleitung (also Soft-Synchronisation) erfordert ein exaktes Regime mit einer Zeitplanung (Scheduler). Daher ist bei synchron-fähigen Transportsystemen grundsätzlich netto < brutto (Datenrate) und die maximale Blocklänge pro Übertragungseinheit begrenzt. In aller Regel werden vom Busmaster äquidistante Zeitmarker (im Drahtlosbereich Beacon genannt) gesendet, aber auch nicht-äquidistante mit Maximalabstand und Zeitinformation sind denkbar.

Hürden

Automatisierungstechniker, Nase rümpfend

„Über USB kann man doch niemals zuverlässig Messwerte übertragen! Wir bleiben bei ModBus und EtherCat. Vielleicht POWERLINK. Synchronisierungsprobleme? Haben wir nicht (bei lächerlichen 1 Sa/s). Messabweichungen? Darum kümmern sich andere (also niemand). Plug-and-Play? Wir stellen die Adressen mit Jumpern ein, dann passt es schon (wer auch immer den Überblick bei 100 Sensoren behält). USB ist doch überhaupt nicht industrietauglich! (Das hatte ich auch mal vom Ethernet gehört.)“

Die Sache verbessert sich jedoch umgehend, sobald es einsatzbereite PnPSA-Geräte gibt. Etwas anfassbares bleibt wesentlich besser im Kopf als ein dicker papierner Standard.

Ausblick (was zu implementieren wäre)

• Billig und teuer! Einfache Sachen wie Temperatursensoren für die Wohnung sollten genauso bezahlbar sein wie bei 100 MHz abtastende Stromwandler für die Halbleiter-Plasmaindustrie, trotz gleichen (USB-)Steckers und gleicher USB-Geräteklasse.
  Für den Profi-Einsatz wäre ein robustes Steckverbindersystem zu überlegen, welches nicht unbedingt USB-kompatibel sein muss. Mir schwebt da ein 10-poliger LEMO/ODU-Stecker vor. Das System sollte auf Verlängerungskabel(!) aufbauen (also keine verschiedenen Stecker für Host und Device). Eingebaute Kodierwiderstände (etwa 100 kΩ pro Meter Kabel) dienen zum Prüfen der maximalen Kabellänge (5 m) auf der Device-Seite. Außer bei USB 3.0 seien nur 5 Pins vorhanden und belegt. Zwei Kontakte (Speisespannung und Masse) sind voreilend.
• Immer mit Einheit! Schluss mit dem manuellen Erstellen praxisgerechter Achsenbeschriftungen.
  LabVIEW bietet beim Datentyp „Signal“ (Waveform) sowie bei Gleitkommazahlen eine Einheit an, eine Darstellung in Graphen ist damit jedoch kurioserweise nicht möglich.
• Nicht nur Messwert, sondern auch Messunsicherheit und Jitter! Eine völlig neue (überfällige?) Herangehensweise, die die Messwertverarbeitung und Fehlerabsicherung revolutioniert.
  Anwendungssoftware wie LabVIEW müsste dahin gehend erweitert werden. Beispielsweise sollte der Datentyp „Signal“ (Waveform) ein Standardattribut „NI_Deviation“ mitführen, welche absolute und relative Messabweichung beinhaltet. Die Graph-Darstellung sollte den Toleranzbereich als entsprechend breite Linie darstellen. Das gilt sinnentsprechend auch für den Jitter, die Varianz der Abtastzeitpunkte. Da Messungen des öfteren mit nicht ganz synchron laufenden Uhren gemacht werden (sicherlich auch künftig), ist eine Angabe der Unsicherheit der Startzeit sinnvoll für eine nachträgliche Korrelierung verschiedener Messreihen. Siehe auch: GUM.
• Absicherung von Kalibrierdaten mittels Public-Key-Verfahren
  (verhindert zuverlässig Piraterie teurer, zertifizierter Sensoren, erzwingt Einhaltung von Kalibrier-Intervallen)
• Vorsetzbare analoge Sensortechnik mit wahlweiser Abspeicherung zugehöriger Kalibrierdaten in einem nichtflüchtigen Speicher des PnP-Sensors und/oder des Computers.
  Beispiel: Vor einem PnP-Differenzdrucksensor (Einheit Pa) wird ein Strömungshindernis angeordnet und anhand der Druckdifferenz der Massenstrom (Einheit kg/s) gemessen. Bei Abspeicherung im Differenzdrucksensor formt dieses Gebilde einen neuen PnP-Sensor (vorteilhaft wenn's eine konstruktive Einheit ist, etwa ein Rohrstück), bei Abspeicherung im Mess-PC nicht (wenn's keine konstruktive Einheit ist).
• Jeder Sensor sollte dringend eine Erkennungs-LED oder sonstige optische Anzeige besitzen, die immer dann blinkt, wenn der Anwender diesen in irgendeiner Form ausgewählt (selektiert, fokussiert) hat. Das ist notwendig, um bei einem Gewirr gleicher Sensoren sicher zu stellen, dass man den richtigen ausgewählt hat. Zusätzlich zu einer seriennummern-basierten Grund-Unterscheidung.
• Nicht nur Sensoren, sondern auch Aktoren!
• Externe Synchronisation und deren Takt-Distribution!
• Unterstützung konfigurierbarer Sensoren (Bereichsumschaltung; Universalmessgeräte) sowohl von Hand (sensorseitig) als auch vom PC (hostseitig)
• Hinreichend sinnvolle Zusammenarbeit mit herkömmlicher, analoger und/oder nicht-synchroner Messtechnik (hierzu zählt auch DDE)!
• PnP-Unterstützung auch für USB-Datenlogger und sonstiger Aufnehmer mit Signalverzögerung!
• Dual-Mode-Sensorik mit alternativem Anschluss, bspw. Hausbus oder Kfz-Bus (Ideenspender: Seriell + PS/2 + USB-Mäuse)
• Unterstützung von dezentraler Messwerterfassung im Anzeigeprogramm!
• Entwicklung eines Speicher-Formats mit Bilddaten-Erfassung
  Lange Zeit habe ich Text-Dateiformate favorisiert. Die Flut an Informationen ist jedoch heutzutage nicht mehr menschenlesbar und Binärformate hinreichend standardisiert, so dass ich mehr und mehr zu einem Binärformat tendiere. Womöglich als Erweiterung zum TDMS-Dateiformat. Es wird schließlich beides unterstützt.

Ziel

• Ein Sensoranzeigeprogramm läuft und stellt Messwerte dar, zeichnet permanent auf (was kostet Festplattenplatz heute und künftig?)
• Ein weiterer PnP-Sensor wird angesteckt
• Das Anzeigeprogramm fügt automatisch diesen Sensor in das Diagramm und die Anzeige ein
• Ein PnP-Sensor wird abgezogen
• Der Graf des Sensors bleibt stehen, die Digitalanzeige verschwindet, alles andere zeichnet weiter auf
• Einer der laufenden PnP-Sensoren ist ein Multimeter mit Messbereichsumschaltung von Hand. Es wird von 20 V auf 200 V Messbereich umgeschaltet: Die Anzeigesoftware reagiert mit einer Aktualisierung der Messunsicherheit (bspw. Breite der Linie)
• Es wird von Spannung auf Strom umgeschaltet: Die Anzeigesoftware beendet den Spannungsgrafen und startet einen Strom-Grafen, etwa als ob ein Sensor abgezogen und ein anderer angesteckt worden wäre; nur Skalierung und Digitalanzeige bleiben an der gleichen Stelle (via Kanal-ID o.ä.)
• Das Programm speichert alle (oder auswählbare) Kanäle für die gesamte Messzeit mit der jeweils nötigen Abtastrate, also Beschleunigungssensoren bspw. mit 10 kSa/s und Temperatursensoren mit 2 Sa/s

Plug-And-Play eben!

Implementation

Dieser Abschnitt beschreibt den etwaigen Werdegang.

Vorarbeiten

Im Vorfeld sollte folgendes abgeklopft werden:

• Vorhandene Standards mit gleichem/ähnlichen Ziel (speziell TEDS)
• Zusammenarbeit mit usb.org zur Erstellung einer neuen USB-Geräteklasse
• Zusammenarbeit mit National Instruments zur Erstellung eines Plugins für den Measurement und Automation Explorer
• Zusammenarbeit mit National Instruments: LabVIEW zur Erweiterung des Signal-Datentyps zur Mitführung der Messunsicherheit (bspw. via Tag) und einer Signaldarstellungskomponente mit Darstellung der Messunsicherheit und Einheit
• Erweiterung der LabVIEW-Signalverarbeitungskomponenten (Addition, Mittelwert, RMS usw.) zur Verarbeitung dieser Messunsicherheit gemäß Fehlerfortpflanzungsgesetzen
• Erstellung eines Dateiformats (binär, kompakt) für die Ablage synchronisierter und nicht-synchronisierter Messergebnisse
• Keine Zusammenarbeit mit AMS (ich habe jBEAM gesehen, das reicht!!)
• Kein Aufsetzen auf USB-TMC (Test&Measurement Class): Diese bietet überhaupt kein PnP
• Deskriptorsystem für Zusammenarbeit mit herkömmlicher, analoger und/oder nicht-synchroner Messtechnik
• Das Anzeigeprogramm muss mit kurzzeitigen (=interpolieren, Einzel-Samples) und langen (=aussetzen, mehrere Samples) Sensor-Ausfällen zurechtkommen, wie in der Wettermesstechnik üblich

Werdegang

• Erstellung des PnP-Sensor/Aktor-Systems anhand von neuen Deskriptoren:
  • Sensoren dürfen, nach ihrer Wahl, linearisierte und/oder nicht-linearisierte Werte liefern
  • Reduktion der Datenanfalls auf ein Minimum; Vorbild: HID (Human Interface Device, USB-Geräteklasse)
  • Sensoren müssen eine physikalische Einheit liefern; Vorbild: HID
  • Sensoren müssen Genauigkeitsangaben liefern:
    • konstant oder formelmäßig per Deskriptor
    • pro Messwert
    • pro Messwert-Bündel bei schnelleren Geräten
    • Änderungsmitteilung am Messwert (bspw. Leistungsmessung bei sich änderndem, sehr kleinen Leistungsfaktor)
  • Mehrsprachigkeit im Deskriptor
  • Mehrsprachigkeit via Wörterbuch-Tags
• Einschluss bereits vorhandener, aber spezieller PnP- und Nicht-PnP-Sensortechnik
  • USB-HID
    • HID-Browser (Darstellung der Collections und Datenelemente eines HID-Gerätes im Baum-Diagramm)
  • USB-Audio (bspw. Schallpegelmessung, Modalanalyse mit Impulshammer)
  • USB-Messkarten (sofern Interface offengelegt)
  • Nicht-USB-Systeme
  • Nicht-PnP-Systeme
• Implementation von Referenz-Sensoren
  • Bereits verfügbare digitale (wertdiskrete) Sensoren (erspart A/D-Wandler)
    • Temperatur- und Feuchtesensor (auf Basis Sensirion SHT21), etwa 10 Sa/s max.
    • Differenzdrucksensor (auf Basis Sensirion SDP610), bis 1 kSa/s
    • Drehwinkelgeber (typ. 10 kSa/s)
  • Analoge Sensoren
    • Kraftsensor mit Dehnmessstreifen-Brücke (bspw. 2 kN Zug + Druck), 1 kSa/s
    • Temperatursensor auf Basis von Pt100, etwa 100 Sa/s max.
    • Stromzange (bis 1 MSa/s)
• Implementation einer Referenz-Software (ohne oder mit LabVIEW, ähnlich einem Oszilloskop-Programm)
• Implementation eines Konzentrators
• Nachweis der Funktionsfähigkeit des Ensembles unter verschiedenen Umgebungen
• Aktor-Implementation
• Vermarktung?

Baumkonzept (evolutionsbegleitend)

• PnP-Sensor/Aktorsystem mit Deskriptor-System
  • Nativ (standardmäßig vorhanden und Referenzimplementation)
    • USB
      • (neu zu erstellende) PnP-Klasse
      • HID-Klasse (für langsame Sensorik, max. 1 kSa/s)
  • Eingebunden (vorhanden, erweiterbar, ggf. gegenüber „Nativ“ hinterherhinkend, teilweise Konfiguration [Non-PnP] erforderlich)
    • Seriell (nur mit PnP)
    • FireWire
    • Bluetooth, ZigBee
    • NI Measurement&Automation Explorer?
    • USB Audio
  • Mit Bustreibern (später vorhanden oder vom Anwender nachzuliefern, fallweise Konfiguration [wegen Non-PnP] erforderlich)
    • Ethernet
    • DDE, OLE
    • One-Wire
  • Mit Einzeltreibern (vom Anwender oder Gerätehersteller nachzuliefern)
    • GPIB, SICL, USB-TMC
    • Alles, was noch nicht aufgelistet ist

Warum ich und hier?

Sicher mag es verwundern, ein Elektronik-Thema im Maschinenbau aufzugreifen. Während meines Elektronikstudium war ich ja blind für das Chaos im Maschinenbau-Bereich.

Meine Referenzen (bisherige Arbeiten im Umfeld dieses Projekts), beispielhaft

• Kontakthandschuh (Umgang mit USB, Mikrocontroller, C++, Datenformat-Interpretation, Windows-Programmierung)
• BootSelektor (Umgang mit Ethernet, TCP/IP, Webserver mit CGI, Mikrocontroller, C++)
• RS422 (Umgang mit Hochgeschwindigkeits-Digital-Sensor und LabVIEW)
• Analoges Sensoranschluss-Konzept (Schaffung eines evolutionären, weil auf HBM basierenden, Werkstandards)
• Laborautomatisierung (Windows-Programmierung, C++, Pascal, Schnittstellen-Kommunikation, DDE)

• Kenntnisse über Zeichenkodierung und Internationalisierung (kyrillisch, chinesisch/japanisch, arabisch, thailändisch)