Pünktlich zum 10-jährigen Firmenjubiläum ist es Zeit das Basislager bei Sherpa.Dresden zu verlassen und in die Universellen Werke des Technologiezentrums Dresden zu anderen Software-Schmieden zu ziehen. Universelle Werke Dresden, Haus E Die neue Firmenanschrift lautet: MechLab Engineering UG (haftungsbeschränkt) Zwickauer Str. 46 01069 Dresden
In der kürzlich erschienenen Bitkom Veröffentlichung "Konkrete Anwendungsfälle von Künstlicher Intelligenz & Big-Data in der Industrie" wird das Projekt CartoX² als ein konkreter Anwendungsfall für die Datenverarbeitung von großen Datenmengen und Vorhersage von Fahrzeug-Kommunikations-Parametern mittels K.I. präsentiert. Datenfluss von Fahrzeugen (links) in Big-Data-Cluster (Mitte) und Ausgabe der API (rechts), Grafik: Fraunhofer IVI mit Überarbeitung von Bitkom [PDF] Download Gemeinsam mit Fraunhofer IVI haben wir an der Erstellung des Beitrags mitgewirkt und danken dem Bitkom für das Aufgreifen unserer Arbeit.
Im Rahmen der MFund Konferenz des Bundesministeriums für Verkehr und Digitale Infrastruktur wurden einzelne Projekte auf die blaue Couch des Social Media Teams geladen und durften kurz ihr Projekt vorstellen. Das Resultat ist eine kurzweilige Zusammenfassung des Projekts CartoX², welches sich mit Car-2-X Kommunikation befasst. Hier das Video: https://youtu.be/QQW-4Y8lj4w
Dies ist Teil 3 einer mehrteiligen Serie, welche beispielhaft zeigt, wie mit Hilfe von maschinellen Lernverfahren eine K.I. trainiert wird, die den Zustand einer Maschine in Echtzeit überwachen kann. Die Teile sind folgende: Problemstellung, Lösungsweg und Datenerhebung Training und Evaluation mit Tensorflow 2.0 Deployment und Anwendungsbeispiel mit Tensorflow Serving in Amazon ECS (dieser) Dabei wird ein Neuronales Netz mit Tensorflow 2.0 angelernt, als Tensorflow Serving gepackt und in Amazon Elastic Container Service (ECS) in der Cloud Deployed. Außerdem wird eine simple Beispielanwendung die Sensordaten an den Cloud Endpunkt übertragen und den Maschinenzustand visualisieren. […]
Dies ist Teil 2 einer mehrteiligen Serie, welche beispielhaft zeigt, wie mit Hilfe von maschinellen Lernverfahren eine K.I. trainiert wird, die den Zustand einer Maschine in Echtzeit überwachen kann (Condition Monitoring). Die Teile sind folgende: Problemstellung, Lösungsweg und Datenerhebung Training und Evaluation mit Tensorflow 2.0 (dieser) Deployment und Anwendungsbeispiel mit Tensorflow Serving in Amazon ECS Dabei wird ein Neuronales Netz mit Tensorflow 2.0 angelernt, als Tensorflow Serving gepackt und in Amazon Elastic Container Service (ECS) in der Cloud Deployed. Außerdem wird eine simple Beispielanwendung die Sensordaten an den Cloud Endpunkt übertragen und den Maschinenzustand visualisieren. […]
Dies ist Teil 1 einer mehrteiligen Serie, welche beispielhaft zeigt, wie mit Hilfe von maschinellen Lernverfahren eine K.I. trainiert wird, die den Zustand einer Maschine in Echtzeit überwachen kann (Condition Monitoring). Die Teile sind folgende: Problemstellung, Lösungsweg und Datenerhebung (dieser) Training und Evaluation mit Tensorflow 2.0 Deployment und Anwendungsbeispiel mit Tensorflow Serving in Amazon ECS Dabei wird ein Neuronales Netz mit Tensorflow 2.0 angelernt, als Tensorflow Serving gepackt und in Amazon Elastic Container Service (ECS) in der Cloud Deployed. Außerdem wird eine simple Beispielanwendung die Sensordaten an den Cloud Endpunkt übertragen und den Maschinenzustand visualisieren. […]
As long as you develop on your local machine, the world is nice and you are probably the only client asking for something which is probably most of the time a correct request. If you are releasing your code to the internet, you will face a lot of bots and wrong requests and automated tools to find bugs in your app. See some logs of our CartoX API running in the Internet: INFO:werkzeug:104.152.52.61 – – [31/Dec/2018 08:33:06] “GET / HTTP/1.0” 200 – ERROR:werkzeug:104.152.52.61 – – [31/Dec/2018 08:33:06] code 400, message Bad request syntax (‘HELP’) INFO:werkzeug:104.152.52.61 – – [31/Dec/2018 08:33:06] “HELP” HTTPStatus.BAD_REQUEST – ERROR:werkzeug:104.152.52.61 – – [31/Dec/2018 08:33:11] code 400, message Bad request syntax (‘DmdT\x00\x00\x00\x17\x00\x00\x00\x01\x00\x00\x00\x00\x11\x11\x00ÿ\x01ÿ\x13’) INFO:werkzeug:104.152.52.61 – – [31/Dec/2018 [...]
Ein weiteres erfolgreiches Jahr neigt sich dem Ende und es ist Zeit, einen Blick auf das Geschaffte zu werfen. Hier eine Auswahl unserer Projekte aus dem Jahr 2018, für welche keine Geheimhaltungsvereinbarung geschlossen werden musste und über die man in einer gewissen Oberflächlichkeit berichten kann: […]
One charming way of versioning a software is to use the GitLab CI/CD and deploy with Tags. Feature Branches will be merged in Development and a version is then merged to Master. These versions may then be tagged with a version number. If the App will be deployed with Docker, a nice feature would be to have the actual build version number or tag as a variable inside this container to show in the app (e.g. that a customer or partner can see which version is running). There might be other solutions, but we found the following very handy. […]
While working on our research project CartoX², we had to deploy a Machine Learning model for prediction of the received signal strength with V-2-X communication ITS-G5 (German name: WLANp). We will use a very simple and easy to understand linear prediction model and serve an API via a Docker container. Up in running in less than 1 hour! […]