Embedded, From Technology to Product.

From mobility to industrial devices, our software delivers smart connectivity and product differentiation.

PARTNERS & CLIENTS

Core Capabilities

Three core capabilities

Cyber Security
Threat analysis and security design, implementation, verification and certification to ISO/SAE 21434 and R155
- CSMS · TARA
- Crypto · Security Lib
- Pen Test
Automotive
AUTOSAR design, implementation and verification on ISO 26262 functional safety and the ASPICE process
- AUTOSAR · Mobilgene
- Telematics · Connectivity
- OTA · Update
Edge Device Connectivity
Development, verification and security from precise sensor and industrial equipment control to home IoT
- OS (RTOS · Linux · Android)
- PLC · IoT · Matter
- Static · Dynamic Analysis

What We Do

Embedded · Software Engineering

From requirement definition to mass-production verification, a V-model process folds hardware constraints and safety and security requirements into design from the start.

Requirements · System design

Functional and safety requirements and hardware limits are fixed as design and verification criteria, cutting rework later in mass production.

Separating requirements Functional and safety requirements (HARA, ASIL) defined separately and kept traceable
Designing to the limits A software architecture that accounts for memory, power and heat, with a step-by-step verification plan
Choosing the standard Whether to use AUTOSAR Classic or Adaptive, decided by what the project needs

Board bring-up · Board support package (BSP)

We bring up the bootloader, kernel and drivers on the target board, and secure a BSP build environment anyone can reproduce.

Board porting Bootloader, kernel and drivers brought onto the target board, peripherals verified one by one
A reproducible build A Yocto-based BSP so anyone building it gets the same result
Early numbers Boot time and memory use measured early, setting mass-production targets from the start

차량용 운영체제의 안전 영역과 서비스 영역을 분리하고 복구 체계를 구성한 모습

Operating system · Platform

The OS, its isolation and its recovery path are shaped around real-time needs, the app ecosystem and update requirements.

Choosing the OS QNX or an RTOS where timing is critical; Linux or Android Automotive (AAOS) where an app ecosystem matters
Separating domains Safety functions kept apart from infotainment, using containers or a hypervisor
Built for OTA A/B partitions with automatic recovery if an update fails

Vehicle HMI · Middleware

The vehicle display and the sensor and service communication are developed together, giving a consistent experience and a steady flow of data.

Vehicle display (HMI) Qt and QML screens built to keep frame drops to a minimum
In-vehicle networks Middleware for service communication (SOME/IP), the control network (CAN) and automotive Ethernet — developed and integrated
Domain applications Navigation, media, climate and other service-layer functions

Integration testing · Functional safety

Requirements, functional safety and security verified through hardware-in-the-loop, real vehicles and static analysis — catching regressions early.

Coverage Requirements confirmed through hardware-in-the-loop and real-vehicle testing
Standards followed ISO 26262 functional safety · ISO/SAE 21434 cybersecurity (TARA)
Blocking regressions MISRA C static analysis and unit and integration tests wired into CI

Optimisation · Mass production

Boot time, response and memory are brought to target, and flashing, inspection and update are connected to the production line.

Meeting the targets Boot time, response latency and memory profiling
On the production line Flashing and inspection, with UDS diagnostics support
Regulation and upkeep Meeting UN R156 for software updates, and putting the after-production process in place

Applications