SrcCode

SrcCode IT, Automotive, C++

🚗📄 Automotive chciało uporządkować software... i stworzyło kolejny potężny proces, który zaczyna dusić inżynierów. Też t...
28/05/2026

🚗📄 Automotive chciało uporządkować software... i stworzyło kolejny potężny proces, który zaczyna dusić inżynierów. Też tak to widzicie?

Jeszcze kilka lat temu w wielu firmach embedded traktowało się ASPICE jako „zło konieczne” pod audyt klienta. Dziś cały automotive software development jest nim przesiąknięty od A do Z.

Jasne – przy projektach tej skali standaryzacja jest potrzebna, żeby nie wjechał totalny chaos i "hero engineering" (gdzie cała wiedza o systemie jest tylko w głowie jednego seniora).

Problem w tym, że w wielu organizacjach proces, który miał ograniczać złożoność... sam stał się osobnym, biurokratycznym potworem. 🩸

Jak to wygląda w codziennej, programistycznej praktyce?
🛠️ Więcej czasu spędzasz na walce z narzędziami i utrzymywaniem ręcznych macierzy traceability niż na pisaniu kodu.
📄 Dokumentacja jest pudrowana i pisana typowo „pod audytora”, a nie po to, żeby realnie komuś pomogła.
👥 Trwają niekończące się statusy o statusach, a "process compliance" staje się ważniejszy niż czysta, stabilna architektura.
💻 Zamiast siedzieć w debuggerze, programiści klną pod nosem, przeklikując tickety w Jirze, Doorsach czy Excelu.

Największy paradoks? ASPICE projektowano lata temu dla znacznie prostszego świata klasycznych ECU. Dzisiaj próbujemy go na siłę rozciągnąć na świat nowoczesnych Software-Defined Vehicles (SDV), ciągłej integracji (CI/CD) i szybkich aktualizacji OTA. Efekt? Zamiast zwinności mamy "checkbox engineering" i iluzję kontroli nad projektem. 🛑

💬 Szybki, anonimowy rachunek sumienia w komentarzach:

Ile procent Waszego czasu w pracy zajmuje dziś realna inżynieria / kodowanie, a ile „karmienie procesu” i papierkologia pod ASPICE?

📊 20% proces / 80% kod?
⚖️ Pół na pół (50% / 50%)?
🚨 A może proporcje już dawno obróciły się w drugą stronę?

Wrzućcie swoje szacunki i dajcie znać, czy to perspektywa z OEM, czy Tier 1/2! 👇

🚗 Najdroższa funkcja we współczesnym samochodzie? Ta, której... prawie nigdy nie używasz.Przez lata koncerny motoryzacyj...
26/05/2026

🚗 Najdroższa funkcja we współczesnym samochodzie? Ta, której... prawie nigdy nie używasz.

Przez lata koncerny motoryzacyjne uczyły nas, że im więcej opcji, tym bardziej "premium" jest auto. Kolejne tryby jazdy, dziesiątki konfiguracji ekranów, ukryte pakiety i tysiące linii kodu.

Efekt? Dzisiejszy samochód to bardziej jeżdżący komputer niż mechanika. I tu zaczyna się gigantyczny problem: EKSPLOZJA ZŁOŻONOŚCI. 🤯

Każda, nawet najmniejsza opcja dorzucona do cennika to dla producenta potężne koszty i miesiące pracy:
🧪 Miliony dodatkowych testów (żeby nowy soft nie zepsuł np. hamulców albo klimatyzacji).
🌍 Tworzenie dziesiątek wersji pod różne kraje i przepisy.
🔐 Ciągła walka z hakerami i zabezpieczaniem systemów sieciowych auta.
📱 Ryzyko "cegły", czyli błędu, który zablokuje auto podczas bezprzewodowej aktualizacji.

A rzeczywistość? Większość kierowców nigdy nie użyje połowy z tych funkcji, nie otworzy instrukcji, a o części opcji w ogóle nie ma pojęcia. 📉

Na slajdach w salonie wygląda to pięknie. W codziennym utrzymaniu kodu i serwisowaniu – koszmarnie. Złożoność nie rośnie liniowo, ona rośnie wykładniczo. Problemem nie jest jedna funkcja, ale miliony kombinacji, które mogą pójść nie tak. Dlatego dziś auta częściej blokuje awaria software’u niż usterka silnika.

Wygrają producenci, którzy wreszcie postawią na prostotę, stabilność i intuicyjny system, zamiast upychać kolejne bajery na siłę. 🎯

💬 Szybka ankieta – jak to widzicie z perspektywy kierowców lub Waszych projektów?

Co jest dziś największym problemem motoryzacji?
🅰️ Wpisz A – Brak realnych, przełomowych innowacji.
🅱️ Wpisz B – Przekombinowanie, nadmiar elektroniki i niepotrzebnych funkcji.

👇 Dajcie znać w komentarzu, co wybieracie: A czy B?

🚗⚠️ Kto powinien mówić „NIE” w projektach automotive?Brzmi trochę dziwnie? A jednak to może być jedna z najważniejszych ...
15/05/2026

🚗⚠️ Kto powinien mówić „NIE” w projektach automotive?

Brzmi trochę dziwnie? A jednak to może być jedna z najważniejszych ról w projekcie.

Bo problem w automotive bardzo rzadko wygląda tak:

💬 „Brakuje nam pomysłów”

Znacznie częściej słyszymy:

💬 „Dodajmy jeszcze jedną funkcję”
💬 „Konkurencja ma coś podobnego”
💬 „To tylko mała zmiana”
💬 „Zmieścimy to jeszcze w tym release”
💬 „Najwyżej dodamy później przez OTA”

I tu zaczyna się ciekawy moment:

👉 Kto powinien powiedzieć: „stop” albo „nie teraz”?

Na początku każda zmiana wydaje się niewielka:
🚗 jeszcze jeden tryb jazdy
📱 dodatkowa funkcja w aplikacji
🎛️ nowe ustawienie w menu
✨ kolejna opcja personalizacji

Ale później okazuje się, że ten „mały dodatek” oznacza:
🧪 więcej testów
📄 więcej dokumentacji
🔄 więcej zależności między komponentami
🔐 wpływ na safety i cybersecurity
🐞 większe ryzyko błędów
📅 większą presję na harmonogram

Różne osoby patrzą na to zupełnie inaczej:
👨‍💼 Product Owner → wartość biznesowa
🏗️ System Architect → wpływ na architekturę
📊 Project Manager → czas i budżet
🛡️ Safety / Quality → ryzyko i zgodność

Najciekawsze jest to, że często wszyscy myślą:

"Jeśli to zły pomysł, ktoś inny go zatrzyma."

A wtedy...

❌ nie zatrzymuje go nikt

I właśnie tak zaczynają się:
🚨 feature creep
🚨 problemy integracyjne
🚨 opóźnienia
🚨 „skąd nagle mamy tyle dodatkowej pracy?”

🎯 Może więc ważniejsze pytanie brzmi nie:

„Kto może powiedzieć NIE?”

ale:

„Kto naprawdę ma do tego mandat?”

💬 A jak wygląda to u Was?

Kto najczęściej zatrzymuje kolejne funkcje:

👨‍💼 Product Owner
🏗️ Architect
📊 Project Manager

czy… nikt? 👇

🔁 Ostatnio pisaliśmy o feature creep, czyli dokładaniu kolejnych funkcji do auta.Dziś druga strona tego samego tematu:👉 ...
06/05/2026

🔁 Ostatnio pisaliśmy o feature creep, czyli dokładaniu kolejnych funkcji do auta.

Dziś druga strona tego samego tematu:
👉 Czy automotive powinno częściej usuwać funkcje, zamiast stale dodawać nowe?

🚗✂️ Feature pruning – mniej może oznaczać lepiej

W branży motoryzacyjnej nowe funkcje dobrze wyglądają w reklamach, prezentacjach i katalogach:
📱 większy ekran
🤖 AI assistant
🎛️ nowe tryby jazdy
✨ kolejne opcje personalizacji
Ale rzadziej zadaje się pytanie:
Czy klient naprawdę tego potrzebuje?

🔎 Czym jest feature pruning?
To świadome ograniczanie lub usuwanie funkcji, które:
❌ są rzadko używane
❌ komplikują obsługę auta
❌ generują koszty utrzymania
❌ zwiększają ryzyko błędów
❌ dublują inne rozwiązania
❌ nie dają realnej wartości
To nie cofanie rozwoju.
To upraszczanie produktu.

🚨 Dlaczego dziś to ważne?
Nowoczesne auta to już nie tylko mechanika.
To także:
⚙️ software
📡 aktualizacje OTA
📱 aplikacje mobilne
🔐 cyberbezpieczeństwo
🧠 systemy ADAS
🌍 wiele wersji rynkowych

Każda nowa funkcja to często:
🧪 więcej testów
📄 więcej dokumentacji
🐞 więcej potencjalnych problemów
💰 większe koszty utrzymania

📉 Przykłady
🔹 skomplikowane menu, z którego nikt nie korzysta
🔹 6 trybów jazdy różniących się minimalnie
🔹 gesty sterowania użyte raz przy odbiorze auta
🔹 dublujące się aplikacje w infotainmencie
🔹 stare opcje utrzymywane „bo zawsze były”

🧠 Najtrudniejsze?
Dodanie funkcji wygląda jak sukces.
Usunięcie funkcji bywa odbierane jak porażka.

A często:
➡️ prostszy produkt = lepszy produkt
➡️ mniej kodu = mniej błędów
➡️ mniej chaosu = lepsze doświadczenie użytkownika

🎯 Wniosek
Nie każda funkcja zasługuje na wieczne życie.
Czasem najlepsza aktualizacja to nie nowa opcja…
ale usunięcie zbędnej.

💬 Jak myślicie — dziś większym problemem w autach jest brak funkcji czy ich nadmiar?

👇 Chętnie poczytamy Wasze opinie.

🚗 Kiedyś liczył się silnik. Dziś liczy się UX.Jeszcze kilka lat temu przewaga samochodu kojarzyła się głównie z tym, co ...
30/04/2026

🚗 Kiedyś liczył się silnik. Dziś liczy się UX.

Jeszcze kilka lat temu przewaga samochodu kojarzyła się głównie z tym, co było pod maską:
🔹 moc silnika
🔹 osiągi
🔹 spalanie
🔹 zawieszenie
🔹 jakość wykonania

I nadal ma to znaczenie.

Ale dziś kierowcy coraz częściej oceniają auto przez pryzmat codziennego użytkowania.
➡️ Czy wszystko działa intuicyjnie?
➡️ Czy system nie irytuje?
➡️ Czy auto współpracuje z kierowcą?
To właśnie UX – User Experience.

📱 Co dziś ma znaczenie?
🔹 szybka i wygodna nawigacja
🔹 sprawne multimedia
🔹 bezproblemowe połączenie telefonu
🔹 dobra kamera cofania i czujniki
🔹 wygodna obsługa klimatyzacji
🔹 systemy wsparcia kierowcy, które pomagają
🔹 aplikacja mobilna, która naprawdę działa

🔋 W autach elektrycznych dochodzą kolejne kwestie:
🔹 realny zasięg
🔹 wygodne planowanie ładowania
🔹 intuicyjna obsługa ładowarek
🔹 zarządzanie energią w trasie

🌍 Dłuższy wyjazd – np. majówka – najlepiej pokazuje, czy auto jest dobrze zaprojektowane.

Po kilku godzinach jazdy mało kto pamięta moment obrotowy silnika.

Ale każdy zapamięta:
❌ zawieszony ekran
❌ słabą nawigację
❌ problemy z telefonem
❌ irytujące alerty
❌ skomplikowane menu

🎯 Dlatego dziś samochód coraz częściej wygrywa nie tylko silnikiem, ale całym doświadczeniem użytkownika.

💬 A Wy na co najbardziej zwracacie uwagę w aucie?
1️⃣ Silnik i osiągi
2️⃣ Komfort jazdy
3️⃣ Multimedia i wygoda obsługi
4️⃣ Systemy wsparcia kierowcy
5️⃣ Niezawodność

Dajcie znać w komentarzach 👇

🔁 Wracamy do posta sprzed roku o feature creep.Przez ostatnie miesiące automotive jeszcze mocniej weszło w świat OTA, so...
20/04/2026

🔁 Wracamy do posta sprzed roku o feature creep.

Przez ostatnie miesiące automotive jeszcze mocniej weszło w świat OTA, software-defined vehicles i ciągłych aktualizacji.

A to oznacza jedno: problem nadmiaru funkcji wcale nie zniknął — wręcz przeciwnie.

🚗 Feature creep w projektach automotive – jak nie utonąć w funkcjonalnościach?

Zaczyna się niewinnie:

➡️ „Dodajmy jeszcze jedną funkcję parkowania.”
➡️ „Konkurencja ma AI assistant – my też musimy.”
➡️ „To tylko mała zmiana w menu.”
➡️ „Resztę dodamy później przez OTA.”

I nagle system, który miał być prosty i stabilny, robi 17 rzeczy naraz… a żadnej naprawdę dobrze.

🔎 Czym jest feature creep?

To sytuacja, w której do projektu dokładane są kolejne funkcje, ale bez odpowiedniego zwiększenia:

📅 czasu
💰 budżetu
🧪 testów
👥 zasobów
🏗️ przygotowania architektury

W automotive to szczególnie ryzykowne, bo jedna mała zmiana potrafi wpłynąć na wiele innych systemów.

⛔ Co wtedy się dzieje?

🔹 chaos w wymaganiach
🔹 problemy z integracją
🔹 mniej czasu na testy
🔹 więcej poprawek po wdrożeniu
🔹 rosnące koszty utrzymania
🔹 coraz większa złożoność produktu

🆕 Jak wygląda to dziś?

📡 „Dodamy później przez OTA”
🤖 „Konkurencja ma AI feature”
📱 „Klient chce UX jak w smartfonie”
💳 „Zróbmy opcję premium na abonament”

✅ Jak się bronić?

✔️ kontrola zmian
✔️ jasne priorytety
✔️ impact analysis przed każdą nową funkcją
✔️ dobra architektura systemu
✔️ dyscyplina testów
✔️ skupienie na wartości, nie ilości funkcji

🎯 Wniosek

Nie każda nowa funkcja poprawia produkt.
Czasem tylko zwiększa jego złożoność.

Najlepsze produkty to nie te, które mają najwięcej funkcji — ale te, które działają najlepiej.

💬 Jak myślicie — dziś większym problemem w automotive jest brak funkcji czy ich nadmiar?

👇 Chętnie przeczytamy Wasze opinie.

Wesołych i pogodnych Świąt Wielkanocnych! Niech te dni będą pełne spokoju, wzajemnej życzliwości i radosnych spotkań z n...
03/04/2026

Wesołych i pogodnych Świąt Wielkanocnych! Niech te dni będą pełne spokoju, wzajemnej życzliwości i radosnych spotkań z najbliższymi. 🪻 🐣 🐇 🌞

Jak naprawdę testujemy pojazdy autonomiczne?Rok temu opublikowaliśmy post, który pokazuje, że to znacznie więcej niż jaz...
30/03/2026

Jak naprawdę testujemy pojazdy autonomiczne?

Rok temu opublikowaliśmy post, który pokazuje, że to znacznie więcej niż jazdy testowe.
Wracamy do niego, bo temat wciąż budzi sporo pytań. 👇

Jak testujemy pojazdy autonomiczne?

To nie tylko jazda próbna. To cała machina: symulacje, prawdziwy sprzęt, dane z floty i analizy w chmurze.
Wszystko po to, by auto zawsze wiedziało, co robić – bez względu na sytuację.

Autonomiczne pojazdy to jeden z najtrudniejszych tematów w dzisiejszym świecie inżynierii.
➡️ Setki czujników
➡️ Miliony linii kodu
➡️ I pełna odpowiedzialność za bezpieczeństwo pasażerów i innych uczestników ruchu

Nie wystarczy, że system zadziała czasami.
On musi podejmować właściwe decyzje w każdej sytuacji – błyskawicznie, niezawodnie i bez wahania.

🔍 Jak więc to wszystko testujemy, zanim pojazd trafi na drogę?

🖥️ 1. Symulacje – MIL, SIL, VIL
📌 MIL (Model-in-the-Loop) – testujemy logikę działania na poziomie modeli, np. Simulinka.
📌 SIL (Software-in-the-Loop) – uruchamiamy rzeczywisty kod na wirtualnym sprzęcie. To już blisko realnych warunków.
📌 VIL (Vehicle-in-the-Loop) – samochód fizycznie "myśli", że jedzie, ale wszystko, co widzi i czuje, to symulacja. Idealne do testowania złożonych sytuacji drogowych.

💻 2. Testy HIL i ECU
🔧 HIL (Hardware-in-the-Loop) – podłączamy prawdziwy sterownik do symulatora i sprawdzamy, jak reaguje na różne scenariusze.
🔧 Na realnym ECU – sprawdzamy komunikację po CAN, obciążenie CPU i czasy reakcji – czyli to, co ma kluczowe znaczenie w realnym pojeździe.

🚦 3. Testy drogowe
Realna jazda – tor testowy, miejskie korki, zła pogoda...
🎯 Tu sprawdzamy, jak system radzi sobie z niespodziewanymi sytuacjami: dzieci wbiegające na jezdnię, dziury w drodze, światła oślepiające kamerę.
To najdroższy etap – ale też ten, który daje najwięcej danych „z życia”.

☁️ 4. Testy rozproszone (edge + cloud)
📍 Edge – komputer pokładowy analizuje dane lokalnie i wykrywa anomalie w czasie rzeczywistym.
📍 Cloud – dane z całej floty trafiają do chmury. Tam je przetwarzamy, szukamy błędów, analizujemy zachowania pojazdu.
To sposób na skalowalne i ciągłe testowanie bez potrzeby budowania ogromnej floty testowej.

🔁 5. Monitoring floty i feedback loop
Każdy samochód testowy to „czujnik na kołach”.
Zbierane dane wracają do zespołów R&D, które tworzą nowe przypadki testowe, poprawiają algorytmy i aktualizują oprogramowanie.
🔄 To ciągła pętla doskonalenia – nic nie trafia na drogę przypadkiem.

🚀 Nowoczesne testowanie to coś więcej niż sprawdzanie, czy działa.
To inżynieria zaufania – bo życie pasażerów i pieszych nie daje drugiej szansy.
💬 A Ty? Z którym z tych etapów testowania miałeś/miałaś styczność?
Symulacje? HIL? Testy w chmurze? A może jazdy próbne?
Daj znać – ciekawi nas Twoja perspektywa! 👇

🌱 Dlaczego auta elektryczne „lubią” wiosnę bardziej niż zimę? ⚡🚗Wraz z cieplejszymi dniami wielu użytkowników EV zauważa...
20/03/2026

🌱 Dlaczego auta elektryczne „lubią” wiosnę bardziej niż zimę? ⚡🚗

Wraz z cieplejszymi dniami wielu użytkowników EV zauważa jedną rzecz:
👉 zasięg nagle rośnie

To nie przypadek — to fizyka.

🔋 Bateria + temperatura

Baterie najlepiej działają w okolicach 15–25°C

Zimą ❄️:
- spada ich wydajność
- szybciej tracą energię
- wolniej się ładują
➡️ efekt: mniejszy zasięg

Wiosną 🌱 wszystko wraca do normy —
➡️ auto zużywa mniej energii i jedzie dalej

🌡️ Zużycie energii zimą

EV zimą nie zużywa energii tylko na jazdę:
❄️ ogrzewanie kabiny
🔋 podgrzewanie baterii
🪟 odmrażanie szyb

➡️ to potrafi „zjeść” kilka kW

W cieplejszych miesiącach ta energia trafia tam, gdzie powinna — czyli na napęd ⚡

⚙️ Małe rzeczy, duża różnica

- rekuperacja działa lepiej w cieple
- ładowanie jest szybsze
- opory toczenia są mniejsze

📉 Różnica? Nawet 20–30% zasięgu

I to wcale nie jest wyjątek.

🎯 Wniosek

EV nie stają się lepsze wiosną.

👉 Po prostu w końcu działają w warunkach, do których zostały zaprojektowane 🙂

💬 A jak u Was?
Zauważyliście różnicę w zasięgu między zimą a cieplejszymi miesiącami?

Rok temu pisaliśmy o tym, jak część rozwoju oprogramowania automotive przenosi się do Indii. 🌏Dziś mam wrażenie, że wart...
11/03/2026

Rok temu pisaliśmy o tym, jak część rozwoju oprogramowania automotive przenosi się do Indii. 🌏

Dziś mam wrażenie, że warto zadać inne pytanie: czy naprawdę chodzi o brak inżynierów w Europie, czy raczej o koszty? 💸

W ostatnich miesiącach coraz więcej osób z branży mówi o czymś innym:
– mniej nowych projektów
– restrukturyzacje w firmach
– zespoły czekające na kolejne programy

A jednocześnie coraz więcej pracy trafia do Indii – powody są jasne: ogromna liczba inżynierów, możliwość szybkiego skalowania zespołów i niższe koszty.

Ale software w samochodach to nie tylko linie kodu. To złożone systemy: ADAS, infotainment, connectivity, zarządzanie energią, OTA i architektury Software-Defined Vehicle. Każdy z tych obszarów musi spełniać rygorystyczne normy bezpieczeństwa.

Dlatego wiele firm stosuje dziś model hybrydowy:
📍 Europa – architektura, bezpieczeństwo funkcjonalne, integracja z OEM
📍 Indie – implementacja funkcji, rozwój platform, testy i utrzymanie

To działa ✅ – ale pojawiają się trudne pytania:
Czy w dłuższej perspektywie nie tracimy kompetencji systemowych w Europie?
Czy architektura i integracja wystarczą, by mieć pełną kontrolę nad produktem?
Gdzie przebiega granica między optymalizacją kosztów a utratą know-how? 💰⚖️🧠

Chętnie poznam Wasze doświadczenia – jak Wy widzicie wpływ globalnych zespołów na projekty automotive? 🌍🚗💻

🤖 Rok temu pytaliśmy: czy AI zastąpi programistów?Dziś AI potrafi już pisać kod, generować testy i pomagać w dokumentacj...
09/03/2026

🤖 Rok temu pytaliśmy: czy AI zastąpi programistów?

Dziś AI potrafi już pisać kod, generować testy i pomagać w dokumentacji.
Sprawdźmy więc, czy odpowiedź się zmieniła.

🤖 Czy sztuczna inteligencja może zastąpić programistów systemów AUTOSAR/ASPICE w motoryzacji? 🚗

Motoryzacja zmienia się na naszych oczach 🔄
AI coraz częściej wspiera tworzenie oprogramowania do nowoczesnych samochodów.

Ale w automotive nie chodzi tylko o to, żeby kod działał.
Systemy muszą być bezpieczne, zgodne z normami i w pełni udokumentowane.

Czy AI jest gotowa przejąć za to pełną odpowiedzialność? 🤔

🧠 Co AI już potrafi?

⚙️ Generuje kod i szablony komponentów AUTOSAR
AI potrafi przygotować szkielety komponentów, standardowe interfejsy, a coraz częściej także fragmenty logiki czy konfiguracji.

🔎 Pomaga w analizie błędów i bezpieczeństwa
Wspiera analizę statyczną i pomaga szybciej wykrywać potencjalne problemy w kodzie.

🧪 Wspiera tworzenie testów
AI potrafi generować testy jednostkowe, proponować przypadki brzegowe i pomagać w analizie logów z testów.

📄 Tworzy dokumentację procesową
Automatyzuje przygotowywanie części dokumentacji wymaganej przez procesy jakościowe.

🔗 Wspiera śledzenie wymagań (traceability)
Pomaga łączyć wymagania systemowe z komponentami oprogramowania i analizować dokumentację projektową.

Brzmi świetnie, prawda? 🙂

⚠️ Ale są rzeczy, których AI nadal nie potrafi

🏗️ Zaprojektować architektury systemu i ocenić wpływ zmian
Myślenie systemowe i analiza zależności między komponentami nadal wymagają doświadczenia inżyniera.

📑 Zagwarantować pełnej zgodności z normami bezpieczeństwa
Procesy takie jak ASPICE czy ISO 26262 wymagają formalnej odpowiedzialności i nadzoru.

🛑 Wziąć odpowiedzialności za systemy krytyczne dla życia
W systemach o wysokim poziomie bezpieczeństwa decyzje nadal należą do ludzi.

🎯 Wniosek

AI w motoryzacji staje się coraz potężniejszym narzędziem 💡
ale to człowiek nadal trzyma stery.

Największą przewagę będą mieli ci, którzy potrafią połączyć
👩‍💻 doświadczenie inżynierskie
z 🤖 możliwościami sztucznej inteligencji.

💬 A jak Wy sądzicie?
Czy za kilka lat zobaczymy samochody, których oprogramowanie powstało w całości dzięki AI?

Dajcie znać w komentarzach 👇

Adres

Ulica Batalionów Chłopskich 8/102
Łódź
94-058

Godziny Otwarcia

Poniedziałek 09:00 - 17:00
Wtorek 09:00 - 17:00
Środa 09:00 - 17:00
Czwartek 09:00 - 17:00
Piątek 09:00 - 17:00

Telefon

+48506147206

Strona Internetowa

Ostrzeżenia

Bądź na bieżąco i daj nam wysłać e-mail, gdy SrcCode umieści wiadomości i promocje. Twój adres e-mail nie zostanie wykorzystany do żadnego innego celu i możesz zrezygnować z subskrypcji w dowolnym momencie.

Skontaktuj Się Z Firmę

Wyślij wiadomość do SrcCode:

Udostępnij