DS LANGUAGEDUALITY CONCEPT

DS Language 프랙탈 시스템 구조

현실 세계의 중첩 구조를 그대로 모델링하는 System of Systems

🌌 프랙탈 구조: 현실 세계의 무한 중첩

마치 러시아 인형(마트료시카)처럼 큰 시스템 안에 작은 시스템이,
그 안에 더 작은 시스템이 무한히 중첩되는 구조입니다.

이런 자연의 중첩 구조를 DS Language가 그대로 구현합니다.

🏭 현실 공장의 프랙탈 구조 예제 (5단계 깊이)
📦 Level 1: 스마트 팩토리 (Project)
전체 공장 = 수십 개의 생산 라인 집합
🏭 Level 2: 자동차 조립 라인 (System)
하나의 라인 = 여러 스테이션의 연결
🤖 Level 3: 용접 스테이션 (Work)
스테이션 = 로봇팔 + 컨베이어 + 센서
🦾 Level 4: 로봇팔 제어 (Call)
동작 = 이동 + 회전 + 그립 + 용접
⚡ Level 5: 모터 신호 (Bit)
신호 = ON/OFF, 속도, 위치, 토크
🔌 Level 6: 전기 신호
24V DC, PWM 신호, 엔코더 피드백...
💡 핵심 통찰
  • 각 레벨은 독립적으로 작동하면서도 상위/하위와 유기적으로 연결
  • 어느 레벨에서든 동일한 패턴이 반복 (Work → Call → Arrow)
  • 상위 레벨은 하위 레벨의 추상화, 하위는 상위의 구체화
  • 무한 확장 가능: 공장 → 공장 그룹 → 글로벌 네트워크...
🤖 생성형 AI 활용의 강력한 기반: 그래프 기반 언어
  • 자기 유사성(Self-Similarity): DS 모델링은 모든 계층에서 동일한 Work-Call-Arrow 패턴이 반복되는 프랙탈 구조 — 하위 시스템도 상위 시스템과 동일한 인과 구조로 설계
  • 무한 확장 가능: System 안에 System을 포함하는 재귀적 구조로 복잡한 대규모 플랜트도 일관된 방식으로 모델링
  • 인과 관계 보존: 계층 간 Arrow 연결이 인과 관계를 명시적으로 표현하여, 어느 수준에서든 원인-결과 추적이 가능
  • AI 생성 최적화: 프랙탈 구조 덕분에 LLM이 작은 패턴을 학습하면 전체 시스템 생성이 가능 — 동일 패턴의 재귀적 적용
  • System of Systems (SoS): 독립적으로 운영되는 시스템들이 ApiDef/ApiCall로 연결되어 더 큰 시스템을 구성 — 각 시스템은 자율성을 유지하면서 협업
🔷 프랙탈 구조 시각화 - System of Systems
📊 시스템 계층 구조 - 하위에서 상위 호출
Level 1 (상위 시스템)
System A
⚡ Work
🦾 Call → ApiCall
📥 ApiDef
System B
⚡ Work
🦾 Call → ApiCall
📥 ApiDef
ApiCall
Level 2 (중간 시스템)
System C
Work
Call→ApiCall
📥 ApiDef
System D
Work
Call→ApiCall
📥 ApiDef
System E
Work
Call→ApiCall
📥 ApiDef
ApiCall
Level 3 (하위 시스템)
System F
Work
Call→Api
📥 ApiDef
System G
Work
Call→Api
📥 ApiDef
System H
Work
Call→Api
📥 ApiDef
System I
Work
Call→Api
📥 ApiDef
📌 핵심 원리
1. 계층 구조
레벨별로 시스템들이 배치
2. 상향 호출
하위 시스템이 상위 시스템 호출
3. 동일 구조
모든 시스템이 Work→Call→ApiCall
4. 프랙탈 반복
각 레벨에서 같은 패턴 반복
🏭 실제 예시
Level 1: MES, ERP
Level 2: 생산라인, 창고관리
Level 3: 로봇, 센서, PLC
하위 시스템들이 필요시
상위 시스템 API를 호출
Project
System
Work
Call
Api 연결
🔄
동일 패턴 반복
Work → Call → Arrow
🔗
System 간 연결
ApiDef ↔ ApiCall
♾️
무한 중첩 가능
System of Systems

이중성의 핵심 원리

  • 동적 역할 전환: 동일한 객체라도 호출 방향, 관찰 관점, 흐름 조건에 따라 다른 역할 수행
  • 관계 기반 해석: 객체 자체보다 인과 연결(Arrow)과 주변 관계에 따라 해석
  • 계층적 추상화: Bit → Call → Work → System → Project 구조로 확장
  • 반복 가능한 흐름 구조: ApiDef → Work → Call → ApiCall → ApiDef → ... 구조가 순환됨

이중성 분류

🏗️ 구조적 이중성 (Cases 1-4)
시스템 구성 요소 간의 설계 및 역할 분리와 관계
Case구성 요소설명
1System ⊕ Device호출 방향에 따라 능동/수동 역할
2Instance ⊕ Reference실행 실체와 참조 대상 구분
3원인(Bit) ⊕ 결과(Bit)흐름 속에서 원인이자 결과
4ReadTag ⊕ WriteTag맥락에 따른 읽기/쓰기 해석
⚡ 실행적 이중성 (Cases 5-8)
실행 시점에서의 상태 변화, 신호 감지, 인과 흐름의 해석
Case구성 요소설명
5WorkBit = R⊕G⊕F⊕HFSM 기반 상태 흐름 표현
6φ(θ) 위상 표현센서 조합 기반 위치 수치화
7Tag = Semantic ⊕ Binding의미 이름과 물리 주소 연결
8Arrow = Start ⊕ Reset인과 신호 역할 분리

상세 Case 설명

Case 1 System ⊕ Device — 동적 역할 전환

DS 시스템은 특정 상황에 따라 "System" 또는 "Device" 역할을 수행할 수 있으며, 이 두 가지는 배타적이지 않고 동적으로 전환됩니다.

🔹 System (Active System)

  • 다른 시스템을 호출하고 실행 흐름을 주도하는 주체
  • ApiCall을 사용하여 외부의 ApiDef 호출
  • 외부 제어 흐름을 개시하고 요청/응답에 대한 책임

🔹 Device (Passive System)

  • 외부로부터 호출되어 동작하는 대상 시스템
  • ApiDef를 통해 외부 요청에 반응
  • 내부 FSM 흐름을 포함하지만 외부 제어 불가

🔹 동적 역할 전환 예시

[상황 1]
A.ApiCall → B.ApiDef
→ A = System (능동 호출)
→ B = Device (응답 수신)

[상황 2]
B.ApiCall → A.ApiDef
→ B = System (능동 호출)
→ A = Device (응답 수신)

🔹 실생활 예시: 제조 자동화

  • 컨베이어 (A) → 로봇팔 (B): 제품 전달 요청 → A는 System, B는 Device
  • 로봇팔 (B) → 컨베이어 (A): 픽업 완료 알림 → B는 System, A는 Device
Case 2 Instance ⊕ Reference — 디지털 트윈 구조

DS 시스템은 실제 물리 시스템과 1:1로 연결되는 디지털 트윈 구조를 갖습니다.

항목InstanceReference
정의 방식new로 생성된 시스템기존 시스템을 참조
실행 가능성✅ Active 설정 시 실행 가능❌ 항상 Passive (읽기 전용)

🔹 설계 및 운영 가이드

  • 새로운 프로젝트에서는 반드시 시스템을 Instance로 정의
  • 동일한 물리 시스템을 참조하고자 할 경우 Reference 구조 사용
  • 시스템 정의 변경은 Instance를 통해서만 가능
  • 순환 참조 및 동일 시스템의 중복 연결 방지 필요
Case 3 Arrow 인과 연결과 Bit 이중성

DS 시스템에서 실행 흐름을 구성하는 최소 단위는 Bit입니다. Bit는 Arrow를 통한 인과적 연결 속에서 원인이자 결과라는 이중적 특성을 지닙니다.

🔹 인과 연결 구조

A (Bit)
B (Bit)
← 결과이자 원인
C (Bit)

🔹 반복 연결 구조

ApiDef
Work
Call
ApiCall
ApiDef
🔄
  • Work(Bit): 시스템 루트에서 선언되는 Bit 그룹, 외부 ApiDef에 의해 트리거
  • Call(Bit): Work 내부에 존재하는 Bit 그룹, ApiCall을 포함
Case 4 Tag = Write ⊕ Read — 데이터 전달

Tag는 시스템 간 데이터 전달을 위한 핵심 인터페이스로, 1:1 연결(Pair)을 전제로 합니다.

🔹 기본 구조

🔧 Active System
Write Tag
물리전송 ⟹⟹
Read Tag
📡 Passive System

🔹 Shared 구조에서의 이중성

조건Read/Write 가능설명
기본 구조Write → Read 1:1 구조 (Pair)
Shared Memory공유 변수처럼 다수 접근 가능
DB 매핑 구조간접 경로로 다수 시스템 접근
Case 5 WorkBit = R ⊕ G ⊕ F ⊕ H — FSM 상태

Work는 네 가지 상태(R, G, F, H)를 가지며, 이 상태는 단일 비트(WorkBit)와 외부 신호 조건에 따라 전이됩니다.

🔹 상태 정의

  • Ready (R): 실행 준비 상태
  • Going (G): 작업 실행 중
  • Finish (F): 실행 완료됨
  • Homing (H): 초기화 진행 중

🔹 상태 전이 다이어그램

🟢 Ready
Start 신호
🔵 Going
완료
🟣 Finish
초기화 완료
Reset 신호
🔴 Homing

🔹 상태 관리 매트릭스

상태진입 조건종료 조건제어 주체
ReadyHoming 완료Start 신호외부
GoingStart 신호내부 작업 완료내부
FinishGoing 완료Reset 신호외부
HomingReset 신호초기화 완료내부
Case 6 φ(θ) = 위상 표현 ⊕ 상태 유추

Work의 센서 입력 및 상태 조건을 기반으로 위상(Phase) 값 φ(θ)를 계산하여 상태를 수치화합니다.

🔹 위상 계산 공식

Binary 기반 (2진법):

φ(θ) = (1/2^n) × Σ(2^(i-1) × Vi × Ci,θ) × 2π

Exponential 기반 (지수 가중치):

φ(θ) = (1/e^n) × Σ(e^(i-1) × Vi × Ci,θ) × 2π

🔹 활용 예시

  • 디지털 트윈 상태 정렬: 실제 설비와 시뮬레이션 시스템의 위상 비교로 동기화 판단
  • 알람/오류 탐지: φ(θ)의 급변 또는 역진행 발생 시 이상 징후로 판단
Case 7 Tag = SemanticLink ⊕ PhysicalBinding

Tag는 의미론적 연결과 물리적 바인딩의 이중적인 역할을 수행합니다.

🔹 구성 요소

구분SemanticLinkPhysicalBinding
정의동작의 의미를 설명하는 이름실제 하드웨어 주소 연결
예시StartCommand, RobotArmReadyX100, Y102, DB100.DBX0.2
용도설계자/사용자 간 의미 전달I/O 연동, PLC 메모리 맵핑

🔹 구조 예시

{
"tagName": "StartSignal",
"semantic": "Start",
"binding": "X100",
"type": "Digital"
}
Semantic 값
Physical 바인딩
데이터 타입
Case 8 Arrow = Start ⊕ Reset — 인과 신호

Arrow는 Work 간의 실행 흐름을 제어하는 신호선이며, StartReset 두 가지 논리적 의미를 동시에 내포합니다.

🔹 신호 생성 조건

신호감지 방식감지 대상용도
Start라이징 엣지이전 Work의 Finish다음 Work 실행 트리거
Reset하이 레벨현재 Work의 Going현재 Work 초기화 조건

🔹 신호 타이밍 다이어그램

시간
t0
t1
t2
t3
t4
t5
t6
Work A
R
G
G
F
F
F
F
Work B
R
R
R
G
G
F
H
Start 신호
0
0
0
1 ↑
0
0
0
Reset 신호
0
0
0
1
1
0
0
↑ = A의 Finish 라이징 ■ = B의 Going 레벨

🔹 실제 적용 예시

컨베이어 완료 (Finish↑)
로봇팔 시작 (Start 신호)
로봇팔 실행 (Going■)
초기화 조건 활성 (Reset 신호)

이중성 설계의 효과

🏗️ 설계 측면
  • 명확한 구성 요소 정의
  • 재사용성 향상
  • 설계-실행 간 추상화 경계 확립
⚡ 실행 측면
  • 흐름 해석의 명시성
  • 자동화 가능성 향상
  • 상태 기반 제어 로직 설계 용이
🔗 시스템 통합
  • 계층 간 결합도 감소
  • 상호 운용성 강화
  • 분산 실행과 참조 기반 설계 공존
🎯 이중성 설계 원칙 요약
  • Bit는 고정된 구조체가 아니라 흐름의 관찰점
  • 모든 구성은 흐름(Arrow) 안에서 원인 ⊕ 결과로 해석됨
  • ApiDef의 지시 및 관찰 인터페이스 존재 여부가 해석 기준
  • 반복 구조 안에서 구조적, 실행적 이중성이 함께 순환됨