Projekty zespołowe

VOLVO - Auto-Analysis of Message Center announcements for Power Platform

The system automatically monitors all Microsoft 365 Message Center announcements that relate to the Power Platform and its components (Power Apps, Power Automate, Dataverse, Copilot for Power Platform, etc.). Whenever a new applicable announcement appears, it goes through an automated analysis process. The results of this analysis are stored in an internal “repository” (e.g., database, SharePoint list, or similar tracking system). Goal: The goal of this initiative is to ensure proactive, consistent, and efficient handling of all Microsoft Message Center (MC) announcements related to the Power Platform. By automating the analysis and classification of these announcements, the organization can reduce manual workload, detect impactful changes earlier, ensure timely communication, and maintain an up-to-date knowledge repository. This contributes to improved platform stability, compliance, and operational readiness. Scope of work: Included in Scope: - Automatic retrieval of all MC announcements related to Power Platform and its components. - Automated classification based on category, priority, and impact. - Automated workflows for planned maintenance, routine updates, and unclear messages. - Creation and maintenance of a structured repository. - Automated stakeholder communication when needed. - Monitoring services such as Power Apps, Power Automate, Microsoft Copilot (Power Platform), Microsoft Dataverse, and overall, Power Platform. - Use of Power Platform and AI/GenAI capabilities to automate classification and summarization. Out of Scope: - Manual investigation of complex or ambiguous MC messages (triggered, not executed automatically). - Handling announcements unrelated to Power Platform. - Full lifecycle management of business-critical changes. - Automatic remediation of issues caused by updates. - Monitoring of non-Microsoft services. Detailed Process Description: 1. Automated Collection & Pre-Processing: - Retrieval of all relevant MC announcements and extraction of metadata. 2. Automated Classification: - Category: maintenance, new feature, breaking change, etc. - Priority: urgency and impact-based. - Impact level across solutions and environments. 3. Automated Actions: A. Planned Maintenance: - Automatic notifications to solution owners and Tenant Admins. - Repository entry updated and closed. B. Regular Service Updates: - Automatic closure with analysis saved. C. Unclear or High-Impact Announcements: - Automated GenAI summary created. - Administrators alerted for review. - Item remains open until resolved. 4. Repository Storage: - All items stored with full history, analysis, actions taken, and status. Technology and tools to be utilized: The technology stack involves Power Platform components, including AI and generative AI capabilities: • Power Automate (Or Agent flows) • AI Builder • MS Copilot Studio (Optional) If needed, the process can integrate signals from other Microsoft services.

Monitorowanie jakosci sieci 5G

Aplikacja webowa do agregowania metryk radiowych, wykrywania anomalii i prezentacji alertow dla zespolu utrzymania.

Asystent organizacji zapisow KPZ

Modul pomagajacy koordynatorom wykrywac konflikty zapisow, kompletowac zespoly i przygotowywac raporty semestralne.

„Dobór i walidacja technologii łączności dla urządzeń transportu bliskiego pracujących indoor/outdoor: LoRa, Wi-Fi HaLow, Wi-Fi i LTE-M/LTE-NB w środowisku przemysłowym”

1. Wstęp Współczesne systemy zarządzania logistyką i magazynami coraz częściej opierają się na automatyzacji oraz cyfrowym monitorowaniu procesów transportowych. Jednym z kluczowych elementów takich systemów są wózki widłowe, które odpowiadają za przemieszczanie towarów w halach magazynowych, centrach dystrybucyjnych oraz zakładach produkcyjnych. Efektywne zarządzanie flotą wózków widłowych wymaga nie tylko optymalizacji tras przejazdu, lecz także niezawodnej komunikacji pomiędzy wózkami a systemem nadrzędnym. Komunikacja ta jest niezbędna do bieżącej aktualizacji pozycji wózków, rejestrowania ich pracy, a także logowania i przesyłania zdarzeń, takich jak kolizje, gwałtowne hamowania, przekroczenia stref bezpieczeństwa czy nieautoryzowane użycie pojazdu. Brak stabilnego i odpowiednio dobranego systemu komunikacyjnego może prowadzić do opóźnień w przesyłaniu danych, utraty informacji lub błędów w systemie zarządzania flotą, co bezpośrednio wpływa na bezpieczeństwo pracowników oraz efektywność operacyjną przedsiębiorstwa. Z tego względu komunikacja bezprzewodowa stanowi jeden z kluczowych aspektów zarządzania flotą wózków widłowych, a jej właściwy dobór ma istotne znaczenie zarówno z punktu widzenia technicznego, jak i ekonomicznego. 2. Opis problemu komunikacji dla wózków widłowych Wózki widłowe pracują w środowiskach o dużym stopniu złożoności, takich jak hale magazynowe i produkcyjne, gdzie występują liczne przeszkody architektoniczne (regały, maszyny, ściany), zakłócenia elektromagnetyczne oraz zmienne warunki pracy. System komunikacyjny musi zapewniać: ciągłą aktualizację pozycji wózka w czasie rzeczywistym lub quasi-rzeczywistym, niezawodne przesyłanie danych telemetrycznych (stan baterii, prędkość, tryb pracy), rejestrację i natychmiastowe raportowanie zdarzeń krytycznych, takich jak kolizje, upadki ładunku czy naruszenia zasad bezpieczeństwa, możliwość logowania operatorów oraz powiązania zdarzeń z konkretnym użytkownikiem. Dodatkowym wyzwaniem jest fakt, że system powinien działać zarówno wewnątrz budynków (indoor), jak i na zewnątrz (outdoor), na przykład na placach przeładunkowych. Wymaga to technologii komunikacyjnej odpornej na tłumienie sygnału, zakłócenia oraz zmiany topologii sieci wynikające z ruchu wózków. 3. Cel i założenia projektu Celem niniejszego projektu jest dobór oraz analiza najlepszego protokołu komunikacyjnego do zastosowania w systemie zarządzania flotą wózków widłowych. Wybrany protokół powinien umożliwiać stabilną, bezpieczną i ekonomicznie uzasadnioną transmisję danych pomiędzy wózkami, a systemem centralnym. Podczas analizy uwzględnione zostaną następujące kryteria: możliwość pracy w środowisku indoor i outdoor, odporność na zakłócenia występujące w halach przemysłowych, zasięg oraz przepustowość transmisji, opóźnienia w przesyłaniu danych (latencja), koszt urządzeń transmisyjnych oraz infrastruktury sieciowej, skalowalność systemu wraz ze wzrostem liczby wózków. 4. Zakres projektu – analizowane protokoły komunikacyjne W ramach projektu przeprowadzona zostanie analiza oraz porównanie wybranych technologii komunikacji bezprzewodowej, które potencjalnie mogą zostać zastosowane w systemie zarządzania flotą wózków widłowych. Celem analizy jest ocena możliwości praktycznego wykorzystania poszczególnych protokołów w środowisku magazynowym i przemysłowym, z uwzględnieniem specyfiki pracy wózków, warunków propagacji sygnału oraz kosztów wdrożenia. Analizie poddane zostaną następujące protokoły komunikacyjne: 4.1 Wi-Fi (IEEE 802.11) Jako rozwiązanie powszechnie stosowane w sieciach lokalnych, Wi-Fi oferuje wysoką przepustowość transmisji danych oraz niskie opóźnienia. Umożliwia przesyłanie dużej ilości informacji, takich jak dane telemetryczne, logi pracy czy zdarzenia w czasie zbliżonym do rzeczywistego. Jednocześnie technologia ta cechuje się ograniczonym zasięgiem oraz podatnością na zakłócenia elektromagnetyczne, które często występują w halach przemysłowych. Wymaga także rozbudowanej infrastruktury punktów dostępowych, co może podnosić koszty wdrożenia i utrzymania. 4.2 Wi-Fi HaLow (IEEE 802.11ah) Wi-Fi HaLow stanowi rozwinięcie klasycznego Wi-Fi, zaprojektowane z myślą o zastosowaniach przemysłowych i Internetu Rzeczy. Technologia ta pracuje w niższym paśmie częstotliwości, co przekłada się na znacznie większy zasięg oraz lepszą penetrację przeszkód, takich jak ściany czy regały magazynowe. Charakteryzuje się niższym zużyciem energii w porównaniu do standardowego Wi-Fi, przy jednoczesnym zachowaniu możliwości dwukierunkowej komunikacji. Może stanowić kompromis pomiędzy przepustowością a zasięgiem w środowisku halowym. 4.3 LoRa (Long Range) LoRa to technologia komunikacji dalekiego zasięgu, zaprojektowana do przesyłania niewielkich ilości danych przy bardzo niskim zużyciu energii. Cechuje się wysoką odpornością na zakłócenia oraz bardzo dobrym zasięgiem, również w środowisku indoor. Z tego względu może być wykorzystywana do okresowego raportowania pozycji wózków, stanów pracy czy zdarzeń alarmowych. Ograniczeniem technologii LoRa jest jednak bardzo niska przepustowość oraz wysoka latencja, co sprawia, że nie jest ona odpowiednia do transmisji danych w czasie rzeczywistym lub do częstych aktualizacji pozycji. 4.4 LTE-M oraz NB-IoT (Narrowband) LTE-M i NB-IoT to technologie komórkowe przeznaczone do zastosowań IoT, oferujące szeroki zasięg oraz wysoką niezawodność transmisji. Dzięki wykorzystaniu infrastruktury operatorów sieci komórkowych umożliwiają komunikację zarówno w środowisku indoor, jak i outdoor, bez konieczności budowy własnej sieci radiowej. Zapewniają dobrą skalowalność oraz wysoki poziom bezpieczeństwa transmisji danych. Ich wadą są jednak koszty abonamentowe, zależność od operatora oraz potencjalne ograniczenia precyzyjnej lokalizacji wewnątrz budynków. 5. Hipotezy badawcze (do weryfikacji) 5.1 H1 (Niezawodność w hali) W środowisku silnie zakłóconym i z przeszkodami metalowymi LTE zapewni najwyższą ciągłość łączności (najmniej zerwań i najmniejszy odsetek utraconych raportów) w porównaniu do Wi-Fi. 5.2 H2 (Koszt vs kontrola infrastruktury) Dla zakładu, który chce uniezależnić się od operatora i kosztów SIM, Wi-Fi HaLow osiągnie lepszy kompromis niż Wi-Fi klasyczne: większy zasięg/penetracja kosztem niższej przepływności, ale wystarczającej do telemetrii i lokalizacji. 5.3 H3 (Telemetria zdarzeń o niskiej częstotliwości) Jeżeli system przesyła głównie krótkie komunikaty zdarzeniowe (alarmy, statusy) i toleruje większe opóźnienia, LoRa będzie najbardziej opłacalna i najbardziej „odporna na zasięg”, ale nie nada się do danych częstych (np. lokalizacja co 1 s) bez kompromisów. 5.4 H4 (Aplikacje wymagające dużej przepływności) Dla przypadków typu wideo, aktualizacja (ang over the air, OTA), diagnostyka bogata w dane — Wi-Fi klasyczne będzie najlepsze przepływnościowo, ale może przegrać stabilnością z LTE/HaLow w deep-indoor. 6. Zadania związane z testowaniem technologii LORA/Halow Wifi/LTE-M Celem tej części projektu jest zbudowanie środowiska testowego (test bed) oraz ocena przydatności technologii do komunikacji w systemie zarządzania flotą wózków widłowych w warunkach zbliżonych do rzeczywistych. 6.1. Budowa środowiska testowego Studenci zbudują środowisko testowe z wykorzystaniem hostów w postaci Raspberry Pi lub NVIDIA Jetson Orin, pełniących rolę serwera zbierającego dane oraz elementów sterujących. W ramach zadania należy: skonfigurować bramę LoRa/HaLow Wifi/Wifi uruchomić komunikację z urządzeniami końcowymi symulującymi wózki widłowe, przygotować oprogramowanie do zbierania i analizy danych transmisyjnych. 6.2. Podstawowe testy transmisji Po uruchomieniu test bedu przeprowadzone zostaną podstawowe testy komunikacji, obejmujące: Jakość transmisji: PDR (Packet Delivery Ratio) / odsetek dostarczonych raportów RTT/latencja end-to-end jitter (zmienność opóźnienia) Zasięg i propagacja: RSSI/SNR (jeśli dostępne) skuteczność w NLOS (za regałami, w korytarzach) działanie na granicy hali (przejścia indoor↔outdoor) 6.3. Testy częstotliwości transmisji i ograniczeń LoRa/HaLow wifi W ramach zadania studenci zbadają ograniczenia technologii LoRa związane z niską przepustowością i duty cycle. Testy obejmą: stopniowe zwiększanie częstotliwości wysyłania danych, ocenę wpływu na opóźnienia i niezawodność, określenie maksymalnej praktycznej częstotliwości raportowania danych. 6.4. Testy skalowalności Przeprowadzone zostaną testy polegające na zwiększaniu liczby urządzeń końcowych (N), w celu: oceny wpływu liczby urządzeń na opóźnienia i straty danych, analizy skalowalności systemu LoRa w środowisku magazynowym. 6.5. Testy w środowisku produkcyjnym Ostatnim etapem będą testy w hali montażowej firmy TSafety, obejmujące: montaż urządzeń końcowych na wózku widłowym, ocenę jakości połączenia w rzeczywistych warunkach przemysłowych, analizę niezawodności transmisji w obecności zakłóceń i przeszkód. 6.6. Analiza ograniczeń prawnych technologii LoRa oraz IEEE 802.11ah i ich konsekwencji technicznych i implementacyjnych (dla ambitnych) W ramach projektu studenci przeprowadzą analizę regulacji prawnych dotyczących pracy urządzeń radiowych w nielicencjonowanych pasmach częstotliwości, wykorzystywanych przez technologie LoRa oraz Wi-Fi HaLow (IEEE 802.11ah). Analiza obejmie zarówno wymagania formalne, jak i praktyczne ograniczenia wynikające z przepisów prawa. W przypadku technologii LoRa, pracującej w pasmach ISM, szczególną uwagę poświęcono: ograniczeniom duty cycle, maksymalnej mocy nadawczej, zajętości kanału radiowego, maksymalnym czasom nadawania, częstotliwość wysyłania pakietów danych, wpływ powyższych na ograniczeń na możliwość realizacji funkcji systemu tj. aktualizacja pozycji czy raportowanie zdarzeń krytycznych. W przypadku technologii Wi-Fi HaLow (IEEE 802.11ah) studenci przeanalizują regulacje dotyczącym pracy w wolnym paśmie sub-1GHz, w tym: dopuszczalne zakresy częstotliwości, limity mocy nadawczej, wymagania dotyczące współdzielenia pasma z innymi system

Opracowanie i weryfikacja algorytmu VSLAM jako źródła lokalizacji urządzeń transportu bliskiego w środowisku produkcyjnym. Ocena dokładności, odporności i wymagania wdrożeniowe

Celem projektu jest zbudowanie stanowiska testowego (wózek widłowy + kamery RGB + edge GPU) i przeprowadzenie eksperymentów w realnej hali w celu oceny VSLAM (ang. Visual Simultaneous Localization and Mapping) w trzech obszarach: (1) dokładność trajektorii, (2) odporność na typowe zakłócenia hali, (3) wymagania integracyjne (kalibracja, synchronizacja, obciążenie obliczeniowe). W projekcie zostanie zastosowana biblioteka PyCuVSLAM. PyCuVSLAM to biblioteka programistyczna w języku Python, stanowiąca interfejs do algorytmów Visual SLAM akcelerowanych sprzętowo przy użyciu kart GPU NVIDIA (CUDA). PyCuVLSAM umożliwia jednoczesne budowanie mapy otoczenia oraz estymacja pozycji i orientacji obiektu (np. wózka widłowego lub robota mobilnego) na podstawie danych z kamer. W odróżnieniu od klasycznych metod lokalizacji stosowanych w środowiskach magazynowo-produkcyjnych (takich jak znaczniki QR, linie magnetyczne czy systemy UWB), PyCuVSLAM nie wymaga infrastruktury zewnętrznej, bazując wyłącznie na analizie obrazu z kamer monocularnych lub stereo. Dzięki temu potencjalnie umożliwia elastyczne wdrożenia w istniejących halach produkcyjnych bez kosztownych modyfikacji środowiska. Wynikiem końcowym projektu będzie raport porównawczy, rekomendacje konfiguracji czujników i minimalny prototyp integracji z urządzeniem NVIDIA Jetson. Cele i pytania badawcze Celem projektu jest sprawdzenie, czy PyCuVSLAM zapewnia wystarczającą dokładność lokalizacji dla zastosowań magazynowo-produkcyjnych (monitoring floty / nawigacja wspomagana / półautonomia). Pytania badawcze: Jaka jest dokładność lokalizacji (ATE/RPE, dryf, stabilność orientacji) w typowej hali? Jak zmienia się jakość przy: różnych prędkościach i manewrach wózka, różnym oświetleniu (dzień/noc, strefy z refleksami), dynamicznych przeszkodach (ruch ludzi/wózków), “featureless” odcinkach (długie białe ściany/korytarze)? Jak trudne jest wdrożenie (kalibracja, synchronizacja, parametry, utrzymanie map)? Hipotezy (H) H1: w stabilnych warunkach (tekstura + poprawna kalibracja) PyCuVSLAM osiągnie błąd rzędu kilku metrów H2: największym ryzykiem degradacji będą synchronizacja, błędy kalibracji i zmienne oświetlenie. H3: multi-camera / więcej obserwacji sceny poprawi odporność w “trudnych” fragmentach hali. 3. Zakres testów offline (przed testami w hali) Celem testów (offline) jest: przeanalizowanie dokumentacji PyCuVSLAM oraz dostępnych przykładów użycia, identyfiacja wymagań sprzętowych i programowych biblioteki, w szczególności: wymagania dotyczące GPU (CUDA), wersje systemu operacyjnego, sterowników oraz bibliotek (np. CUDA, cuDNN), wymagania dotyczące kamer i formatów danych wejściowych, przygotowanie środowiska uruchomieniowego na platformie NVIDIA Jetson Orin, przeprowadzenie portowania i konfiguracji PyCuVSLAM na docelowym hardware, pmplementacja pipeline’u odtwarzania danych, szybka weryfikacja, czy PyCuVSLAM działa stabilnie na danych z wózka (bez ryzyka i kosztów hali), wyłapanie “wąskich gardeł” integracyjnych (kalibracja, synchronizacja, parametry), przygotowanie rekomendowanych konfiguracji (kamery/ustawienia) i scenariuszy na halę. Dane wejściowe (dostarczane przez TSafety) TSafety dostarczy zestaw nagrań z wózka widłowego obejmujący: strumienie wideo z kamer (mono lub stereo; opcjonalnie multi-camera), metadane czasowe (timestampy), jeśli są dostępne, informacje o konfiguracji (FPS, rozdzielczość, ekspozycja, FOV), jeśli możliwe: dodatkowe sygnały pomocnicze (np. IMU, enkodery, log prędkości) – nawet jeśli PyCuVSLAM ich nie wykorzystuje, są przydatne do analizy i “ground-truth”. 3.1 Zadanie: Odtwarzanie danych i uruchomienie PyCuVSLAM w trybie zbliżonym do rzeczywistego Celem zadania jest przygotowanie kompletnego pipeline’u przetwarzania danych, który umożliwi uruchomienie algorytmu PyCuVSLAM w warunkach możliwie zbliżonych do pracy w czasie rzeczywistym, mimo że wykorzystywane będą dane wcześniej zarejestrowane. Studenci przystąpią do zaprojektowania i implementacji systemu, który odtwarza zapisane dane sensoryczne (wideo / obrazy / dane IMU, jeśli dostępne) w taki sposób, aby symulować ich napływ „na żywo”, z zachowaniem oryginalnej częstotliwości próbkowania oraz kolejności czasowej. 3.1.1 Zakres realizacji zadania I. Przygotowanie danych wejściowych. wykorzystanie wcześniej zarejestrowanych sekwencji video lub zestawów obrazów z kamer (monocularnych lub stereo), zapewnienie poprawnego formatu danych zgodnego z wymaganiami PyCuVSLAM, uwzględnienie kalibracji kamer (parametry wewnętrzne i, jeśli dotyczy, zewnętrzne). II. Zaimplementowanie mechanizów odtwarzania danych. a) stworzenie modułu odczytu danych z dysku, który: publikuje kolejne klatki obrazu w zadanym interwale czasowym, symuluje rzeczywiste opóźnienia (np. 30 FPS, 10 FPS), umożliwia zatrzymanie, wznowienie oraz restart sekwencji, zadba o synchronizację czasową danych (jeśli używane są dodatkowe sensory). III. Integracja z PyCuVSLAM uruchomienie PyCuVSLAM w trybie przetwarzania strumieniowego, przekazywanie danyuch do algorytmu dokładnie tak, jak miałyby one pochodzić z kamery zamontowanej na pojeździe, zapewnienie ciągłość przetwarzania oraz obsługę potencjalnych opóźnień obliczeniowych. IV. Monitoring działania systemu rejestrowanie estymowanej pozycji i orientacji w czasie, zapisywanie przebiegu trajektorii oraz mapy środowiska, monitorowanie wykorzystania zasobów obliczeniowych (CPU/GPU) i opóźnienia pipeline’u. 3.2 Efekt końcowy Po zakończeniu zadania studenci powinni dysponować: działającym pipeline’em umożliwiającym realistyczne testowanie PyCuVSLAM bez fizycznego robota lub wózka, możliwością powtarzalnych eksperymentów na tych samych danych, podstawą do dalszych analiz jakości lokalizacji, stabilności algorytmu oraz jego przydatności w środowisku produkcyjnym. 4. Zakres i scenariusze testowe w hali Pętla referencyjna: przejazd po zamkniętej pętli 50–150 m. Długi korytarz: 30–80 m z powtarzalnym tłem (regały). Strefa refleksów: posadzka błyszcząca / światła punktowe. Ruch dynamiczny: przejazd obok pieszych i innego wózka (bez ingerencji w bezpieczeństwo). Manewry precyzyjne: dojazd do palety, cofanie, skręt w miejscu, podnoszenie masztu (sprawdzenie wpływu wibracji i zmian widoku). Restart / relokacja: start z innego miejsca, sprawdzenie jak łatwo wznowić spójny układ odniesienia 5. Metodyka pomiaru “prawdy” (ground truth) System geodezyjny. UWB RTLS jako referencja. markery na wybranych punktach (aruco). 6. Architektura systemu testowego 6.1 Sprzęt Edge GPU: NVIDIA Jetson (np. Orin) lub PC z RTX (jeśli dopuszczalne). cuVSLAM jest projektowany pod real-time na Jetson. Kamera RGB lub/i stereo (np. RealSense / ZED / inna). Mocowanie: sztywne, odporne na wibracje (rama przy dachu kabiny / masztu, ale uwaga na zasłanianie). 6.2 Software PyCuVSLAM (Python) + logowanie trajektorii + narzędzia ewaluacji Alternatywnie/równolegle: ROS (opcja) 7. Metryki i ocena jakości ATE (Absolute Trajectory Error) - błąd pozycji po dopasowaniu do GT. RPE (Relative Pose Error) - błąd odcinkowy / dryf na segmentach. Wydajność: FPS, opóźnienie, użycie GPU/CPU, dropped frames. opis: https://docs.google.com/document/d/1RdwFTTjO0oZ3lt3TFJn7VQ4sbqsk6w94W6mGq3kEQkg/edit?usp=sharing

Robotyczna noga

brak opisu ale będzie!

Robotyczna ręka

Motywacja Napięcia polityczne między USA a UE pogarszają postrzeganie wspólnych wartości przez Europejczyków. Dla Europy, która do tej pory akceptowała dominację amerykańskich big techów i nie konkurowała w obszarze aplikacji webowych, otwiera się okno możliwości na rozwój własnych rozwiązań. W praktyce wiele rozwiązań dla aplikacji webowych już istnieje w domenie open source. Chcesz zrezygnować z Gmaila — możesz hostować własny serwer pocztowy. Nie podoba Ci się Google Drive — możesz uruchomić własny serwer do współdzielenia plików wraz z edytorami online. Nie chcesz, aby Facebook zarządzał Twoją prywatnością — możesz postawić własny serwer Mastodon. Nasz cel Stworzyć zestaw skryptów Infrastructure as Code, które umożliwią automatyczne uruchamianie aplikacji webowych jako alternatywy dla ofert takich firm jak Google czy Meta. Rozwiązania mają być wykorzystywane przez rodziny, społeczności i większe grupy ludzi, aby obniżyć koszty infrastruktury, integrować użytkowników oraz umożliwić im zarządzanie własnymi danymi bez udostępniania ich stronom trzecim lub narzędziom AI. Użytkownicy mają być właścicielami rozwiązań i odzyskać kontrolę nad swoją prywatnością. System ma być samowystarczalny — zawierać mechanizmy backupu, centralne zarządzanie użytkownikami, automatyczne tworzenie i obsługę certyfikatów, podstawowy monitoring oraz możliwość działania zarówno publicznie w internecie, jak i wyłącznie za VPN-em. Celem jest zastąpienie takich usług jak Gmail, Google Drive, Google Calendar, współdzielenie plików i wielu innych przy użyciu oprogramowania open source. Jak to ma działać Użytkownik końcowy nadal musi: Kupić własną domenę. Wykupić hosting (AWS, Azure, Hetzner itp.) albo postawić własny serwer z dostępem do internetu. Po spełnieniu tych warunków skrypty IaC przejmują konfigurację infrastruktury i wdrażają potrzebne aplikacje oraz usługi. Podstawowe i kluczowe skrypty do uruchamiania aplikacji na: serwerze należącym do użytkownika, Hetznerze lub innych dostawcach hostingu będą open source i dostępne bezpłatnie dla wszystkich. Model biznesowy opiera się na sprzedaży usług wokół tych skryptów, takich jak: konfiguracja i zarządzanie infrastrukturą na publicznych hostingach (np. Hetzner) w imieniu klientów i społeczności, usługi konsultingowe dla użytkowników i organizacji korzystających z rozwiązania, w późniejszym etapie — współpraca z europejskimi dostawcami hostingu (np. Hetzner), którzy płaciliby za rozwój i dostosowanie skryptów do swoich platform.

Konfigurator procesow ERP

Interaktywny edytor procesow biznesowych z walidacja zaleznosci i eksportem konfiguracji dla systemu ERP.