쿼츠 블로그를 위해 대공사
This commit is contained in:
@@ -0,0 +1,16 @@
|
||||
Server
|
||||
|
||||
config -> TRANS4 -> startup -> database.properties
|
||||
interface.properties ( environment, server.domain.(mcs).host 개인꺼로 바꿔주기 )
|
||||
( 위 두 파일 설정만 맞춰주면 됨 )
|
||||
|
||||
UI
|
||||
TM18_Client -> plugins -> config.TM18 -> ui.properties
|
||||
|
||||
|
||||
UI_Listener -> MCS 입장에서의 Client들이 보내는 TIB 메시지를 받음
|
||||
Host_Listener -> '' Host가 보내는 TIB 메시지를 받음
|
||||
|
||||
|
||||
MCS에서 JOB은 출발지, 최종목적지에 대한 정보를 의미
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
IB: OHT OHS 등
|
||||
|
||||
SEM?
|
||||
Stocker SEM 이러면 뭔가 Stocker 동작 규약? 그런 뜻인가 봄
|
||||
|
||||
TSC??
|
||||
Transfer SC
|
||||
|
||||
SC? System Control? <---> Semi Conductor?
|
||||
|
||||
OP: Stocker Crane이 닿을 수 있는 최종 ==Out Port==
|
||||
LP: OHT, OHS에 붙어있는 Port ==Loading Port==
|
||||
|
||||
OP <-> LP는 알아서 움직일 수 있다.
|
||||
|
||||
EAP가 반도체설비 대신 물류관련(IB, SC) 설비를 관리하고,
|
||||
반송관련 Order를 내릴 수 있어야 하기 때문에 별도의 DB를 가진다고 생각하면 될 것 같음.
|
||||
@@ -0,0 +1,8 @@
|
||||
|
||||
Area
|
||||
└
|
||||
FACTORY -> AREA -> <U>SHOP</U> -> BAY
|
||||
(Hynix) 잘안씀 많이씀
|
||||
|
||||
INTERSTORAGE 에서 SHELF를 뺀 것 (LIFTER)
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
|
||||
MCS가 TIB으로 누구랑 연결되어 있는지 확인 필요 (이전 교육내용중에 있었음, 교육자료 보면 될듯)
|
||||
|
||||
AbstractMessage
|
||||
└TransferMessage
|
||||
└ TransportMessage
|
||||
둘 다 반송관련 메시지임. 개별 스토커내부의 반송명령에는 TransportMessage를 쓴다.
|
||||
모든 반송명령 메시지는 TransferMessage (혹은 그 자식 클래스)로 처리한다.
|
||||
이 둘의 구분은 명확하지 않다. 이부분에 대해서는 명확하게 확정해주는게 필요하다.
|
||||
|
||||
Heuristic Delay는 별도의 Daemon Server를 통해 주기적으로 계산한다.
|
||||
(하지만 이 기능 자체를 잘 안쓴다고 함)
|
||||
|
||||
alternate, recovery 두가지의 대체반송이 있음
|
||||
alternate는 job이 있고 recovery는 별도의 job이 없다
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
SEM 문서를 기반으로 개발진행
|
||||
SEMI SPEC 문서랑 굉장히 비슷해보임
|
||||
|
||||
MCS가 close connection 하는것과
|
||||
UI에서 offline 처리하는 것은 다르다. (S1F15)
|
||||
|
||||
Carrier cancel은 동작중일때는 캔슬불가
|
||||
(Cancel은 취소, Abort는 중단)
|
||||
|
||||
차세대MCS에서는
|
||||
Client <-> MCS WebServer 이렇게만 통신하게 할 예정
|
||||
이 둘은 HTTP를 쓸거같고 MCS WebServer가 TS든 CS든 얘네들하고 TIB통신을 할듯함
|
||||
|
||||
기존 MCS에서는
|
||||
UI(Client) <-> TS, CS 두곳과 TIB통신으로 직접 통신했었음.
|
||||
|
||||
기존 UI는 메인 화면 띄울때 버벅이는게 있었고
|
||||
설비수가 천대를 넘어가는 큰 사이트의 경우에는
|
||||
처음 화면 띄울때 켜놓고 나갔다와야할 정도라고..
|
||||
한번띄워놓으면 그다음부터는 좀 낫다고..
|
||||
|
||||
Crane이 out of service되면 Crane이 접근가능한 port들도 같이 out of service가 된다.
|
||||
(Crane이 없으면 해당 port들에 접근할 방법이 없으므로)
|
||||
Crane이 in service가 되면 port들도 같이 in service가 된다.
|
||||
|
||||
(Machine)AlarmSet
|
||||
UnitAlarmSet
|
||||
AlarmCleared 순서로? 세트로 발생된다함
|
||||
|
||||
Machine Alarm, Unit Alarm이 각각 의미하는 바가 있나봄
|
||||
Machine은 설비 그자체,
|
||||
Unit은 Machine에 포함된 Port같은 유닛들을 의미
|
||||
|
||||
Rail OHT는 (일반적으로)Port가 없고
|
||||
Interail은 있다. ?
|
||||
@@ -0,0 +1,9 @@
|
||||
컨플, 지라 확인 (메일 보낸거중에 있음)
|
||||
|
||||
RCP 걷어내는건가?
|
||||
-> ㅇㅇ
|
||||
|
||||
WBS문서 보는방법을 확인하자
|
||||
-> 해야할 일을 정의하고 일정을 어느정도 산정해봄
|
||||
WBS기준으로 JIRA 작성됨
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
Front 화면 설계
|
||||
오븐써서 그린다는 거 같음.
|
||||
|
||||
설계의 범위가 어느정도까지여야 하는가?
|
||||
![[2023-12-14 Client 회의]]
|
||||
@@ -0,0 +1,6 @@
|
||||
WEB UI 설계 - WEB UI 화면 설계
|
||||
|
||||
'이력 조회' '사용자 관리' 'Application 관리' 'Data 조회' '기준 정보 관리 - 모델링' 화면 설계하면 됨.
|
||||
|
||||
화면 설계?
|
||||
: 카카오 오븐으로 프로토타입 제작
|
||||
@@ -0,0 +1,13 @@
|
||||
1. 프로젝트 신규투입인원 오리엔테이션
|
||||
2. 프로젝트 관련 질답 ( 컨플에 자유롭게 게시글작성해도 됨, )
|
||||
3. ==2024.01.11 목요일날 WFB, WFL 관련 교육받아야 함.==
|
||||
4. WBS Gant-Chart에 상위분류에 담당자는 하위분류에 있는 업무들을 관리해야함.
|
||||
5. 화면 개발 관련 정기 회의 : 매주 화,목 오전 10시 30분. 회의실은 예약하는데로 공유
|
||||
|
||||
Backend: 성능개선, IOBridge_SECS 사용으로 변경
|
||||
Frontend: Web으로 변경, UX 개선 (기존과 차이가 많이 나면 안됨)
|
||||
|
||||
**기존에 UI app을 Web버전으로 변경한 적이 있었는데
|
||||
(너무 많이 변해버린 UI/UX로 인해) 못쓰겠다고 해서 다 걷어낸 이력이 있다고 함.
|
||||
지금 쓰고있는 .NET버전의 UI대비 많이 변하면 안됨**
|
||||
|
||||
@@ -0,0 +1,26 @@
|
||||
aim의 DB설계컨셉
|
||||
1. 기준정보 테이블 따로, 현재 데이터 따로
|
||||
2. ?
|
||||
|
||||
key join
|
||||
|
||||
NXMCS의 DB Table Hierachy
|
||||
FACTORY
|
||||
AREA (SHOP이랑 BAY는 어디로??)
|
||||
EQUIPMENT
|
||||
Unit
|
||||
Port
|
||||
Shelf
|
||||
|
||||
ProhibitTransport: 현재 위치 기준, 반송 불필요 Bay 연결 정보
|
||||
|
||||
Transport Command : 실제 설비로 내려지는 반송명령 그 자체를 의미
|
||||
Transport Job은 무엇?
|
||||
|
||||
Transfer -> Transport 용어 변경,통일
|
||||
|
||||
InterNode != IntraNode, 개념설명 x
|
||||
Inter와 Intra 단어 뜻 그대로 사용되는 개념인가봄
|
||||
|
||||
MCS에서의 Node는 Equipment 이하의 개념들을 의미하는가?
|
||||
( Equipment, Unit, Port, Shelf )
|
||||
@@ -0,0 +1,15 @@
|
||||
기준 정보 관리 - 모델링 start , end date 다시 할당하기
|
||||
|
||||
업무들에 할 일 형태로 설명에 있는 업무들 추가해주기
|
||||
|
||||
2월9일까지 할당량 다 할 수 있는 일정으로 업데이트
|
||||
|
||||
|
||||
반송설비
|
||||
-> 저장 + 반송
|
||||
-> only 반송
|
||||
|
||||
두가지로 나뉨.
|
||||
|
||||
machine -> equipment 로 용어 통일
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
????
|
||||
@@ -0,0 +1,7 @@
|
||||
6월까지 (6월30일) 개발 완료
|
||||
|
||||
FrontEnd는 일단 4월까지 (아마 3월31일까지 인듯) 해보고
|
||||
안되면 김동균선임 추가 투입
|
||||
|
||||
2월5일~8일 화면 설계 Review
|
||||
|
||||
+18
@@ -0,0 +1,18 @@
|
||||
1. 디자인 시안 리뷰 (제안)
|
||||
- micro-copy = 좋아요 ? 좋아요 기능을 이야기하는 것 같음. UX에서 쓰는 은어같은것인가봄
|
||||
- aim제품의 UI 통일성이 부족함
|
||||
-> A set (Factory Modeler와 비슷한 시안) 제안
|
||||
-> Q. B set는 그럼 뭐랑 비슷한가요? -> 개방감을 위주로 새로 한 시안인듯
|
||||
( 못 물어보겠다 회의분위기가.. )
|
||||
- UI / UX 제안인데, 설계 다 끝나가고 리뷰를 다음주에 하는데 지금 제안을 주는게 맞는것인가?
|
||||
- UI / UX 제안서를 봤는데 기존이랑 크게 달라지는게 없는거 같은데?
|
||||
( C# 프로그램에서 WebApp으로 바뀌는데 WebApp으로 구현하기엔 화면 하나에 표현되는 정보가 너무 많은 경우가 있는 것 같음. )
|
||||
-> 이거에 대해서는 특별히 해결책이 제시되지도, 의논되지도 않았음
|
||||
- 이번 NXMCS 프로젝트 부터는 퍼블리싱이 먼저 나오고 front 개발 진행되는 식으로
|
||||
바뀔수 있으..려나?
|
||||
- favorite 메뉴를 원래 C# UI Program에서 관리한거 같음. user table에 추가해서 이제 서버가 관리하는 식으로 바뀔 것 같음.
|
||||
- 우측 information 탭 사용함
|
||||
- properties -> select 한 grid item에 대한 properties를 나열해주는 우측 information
|
||||
- 설비, 유닛별 메모기능 -> Excel 메모처럼 보여져야 한다?
|
||||
|
||||
화면 시안 A, B 중 맘에드는거 하나 골라놓자.
|
||||
@@ -0,0 +1,17 @@
|
||||
Q: 컨텍스트 메뉴는 한땀한땀 만든것인지?
|
||||
: ㅇㅇ (노가다)
|
||||
|
||||
Online Remote는 Heart Beat 기능의 일종인가?
|
||||
( Are you there? 같은 그런 느낌의 )
|
||||
|
||||
서버에게 정보 전송 -> reply 오거나 안오기까지
|
||||
|
||||
Wating Reply -> Success -> Success 상태를 알려주기 위한 문자열
|
||||
-> Timeout
|
||||
요런 순서로 버튼 클릭 시 동작이 잘 작동되고 있는지 알려주는 아이디어
|
||||
progress button
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
JIRA 업데이트 해줄 것
|
||||
|
||||
화면설계 피드백
|
||||
-
|
||||
@@ -0,0 +1,62 @@
|
||||
el, trans 이름
|
||||
MCS Management 우클릭메뉴 없음
|
||||
|
||||
|
||||
SECS Interface 화면
|
||||
그리드에서 바로 데이터를 수정하는건 안쓰는걸로
|
||||
보관함
|
||||
|
||||
프로퍼티 다시그리기
|
||||
페이징 빼기
|
||||
|
||||
|
||||
Resource Management
|
||||
아이템에 따라 화면 다 내가 다 그려줘야함
|
||||
State
|
||||
다른화면 참고 필요
|
||||
|
||||
|
||||
AlarmSpec management
|
||||
버튼 다른화면이랑 비교해서 바꾸고
|
||||
모달에서 정보 수정하도록
|
||||
|
||||
|
||||
Alternate Storage management
|
||||
트리에서 우클릭, 그리드에서 우클릭 (Alternate Storage 그리드)
|
||||
|
||||
|
||||
|
||||
Empty Carrier Balance Management
|
||||
EQP ID가 PK라서 GroupName만 받아서 Group을 만들 수 없다.
|
||||
DB Table 구조 excel 확인하면서 그려야함. (
|
||||
|
||||
|
||||
|
||||
- MCS Application Management
|
||||
→ 기존 구조를 따르되, 기존 Primary/Secondary에서 MCS 갯수대로 넘버링하고, UI로 표시함. (페이징)
|
||||
→ 우클릭 메뉴에 대한 내용이 누락되어 확인하여 추가 예정.
|
||||
- SECS Interface Management
|
||||
→ AS-IS DB가 아닌 최신화 된 DB 컬럼 기준으로 설계할 것.
|
||||
→ Grid Edit방식으로 설계했는데, 다른 Create/Modify/Delete 패턴을 참조하여 수정할 것.
|
||||
→ SECS Reference 화면 설계 누락되어 확인하여 추가 예정.
|
||||
- Resource Managment
|
||||
→ 좌측 트리 클릭 대상(Type)에 따라 조회된 데이터가 출력 되는 화면이 다름. Main에서 넘어오는 경우도 있음. (논의 필요)
|
||||
→ State 부분도 이미 결정된 내용을 따라 재설계할 것.
|
||||
- AlarmSpec Manangement
|
||||
→ Create/Modify/Delete 패턴 참조하여 재설계할 것.
|
||||
- Alternate Storage Management
|
||||
→ 기존 팝업 화면에서 한페이지에서 조작할 수 있도록 설계함. (Modal 방식이 나을지는 좀 더 고민 필요.)
|
||||
→ Alternate Storage 그리드에 우클릭 컨텍스트 메뉴 추가.
|
||||
→ Undo 제거, 순서 변경 기능 추가할 것.
|
||||
- Recovery Dest Management
|
||||
→ Alternate Storage Management와 동일한 UI 패턴으로 설계함.
|
||||
- Empty Carrier Balance Management
|
||||
→ Add New Group 버튼 클릭시 AS-IS와 동일하게 Modal로 추가할수 있도록 함. 단, Machine 정보도 같이 입력할 수 있도록 Modal창에 선택 화면 추가할 것.
|
||||
→ 기타 이미 의사결정된 UI 요소들을 참조하여 재설계 할 것.
|
||||
- Port Priorty Management
|
||||
- MachineAlias Management
|
||||
- UnitAlias Management
|
||||
- User
|
||||
→ User 메뉴, 권한 부분은 논의 필요.
|
||||
- 이력 조회
|
||||
→ Grid base의 단순한 구조로 변경할 것.
|
||||
@@ -0,0 +1,5 @@
|
||||
따라가기가 힘들다..
|
||||
|
||||
컨플런스 회의록 댓글에 변경되는 사항들에 대해 등록을 하겠음.
|
||||
: 컨플런스 알람이 오는 것 같은데, 한번 알람왔을 때 확인 안하면 알람표식이 꺼지는거같음.
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
반응형 화면 대응
|
||||
→ 현재, 가로 사이즈 1280 이하 디바이스에서는 대응하지 않는 문제가 있음.
|
||||
→ 1280 이하에서는 상단 메뉴 위치를 왼쪽에 대응 하는 방식으로 적용한다.
|
||||
|
||||
퍼블리싱 우선순위
|
||||
→ 현재, 메뉴 기준으로 우선순위가 설정되어 있고, 그에 따라 개발 계획이 잡혀있음.
|
||||
→ 레이아웃 → 메뉴 순으로 개발 우선순위를 두어야 함.
|
||||
|
||||
- Client 개발
|
||||
→ 소스 충돌 방지 위해 퍼블리싱 소스를 Tag Branch단위로 관리한다.
|
||||
( )
|
||||
→ 화면 개발시 이를 참고하여 개발 한다.
|
||||
@@ -0,0 +1,8 @@
|
||||
Jira에 하위 일감을 그때그때 잡은 job에 추가해서 진행
|
||||
|
||||
sprint5 시작할 때 개발자 추가 투입 검토 예정
|
||||
|
||||
모달 기존 WFL거 말고 새로 만들어서 씀
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
1. 모달창 전부 제대로 그리기
|
||||
2. 우측 properties 창 properties 아닌거 같은것들 수정
|
||||
( 전정현선임 69page )
|
||||
3. Alias가 Unit, Port, Zone, Equipment 네가지로 나뉘어짐.
|
||||
( 네개를 한 화면에서 할 수 있을까? )
|
||||
4. History 새로 그리기 (EAS 화면 기준으로)
|
||||
( The Latest: 10초, 30초, 1분, 5분, 10분, 30분 )
|
||||
( 검색시간 제한이 필요함. 너무 많은 데이터를 조회하면 안됨 )
|
||||
( 하이닉스는 10분 초과 시 confirm 화면을 한번 띄움 )
|
||||
|
||||
http://211.60.157.241:8090/pages/viewpage.action?pageId=50075248
|
||||
History 검색조건 중요도 순서
|
||||
@@ -0,0 +1,4 @@
|
||||
- UX는 비슷하게, UI는 새롭게 (????)
|
||||
- 동적 화면 구성에 대해 고민해봐라 (????)
|
||||
- Multi Select 방식을 고려해봐라 (???????)
|
||||
|
||||
@@ -0,0 +1,9 @@
|
||||
- 플랫폼개발팀에서 만든 로그뷰어를 써야한다. ( 로그뷰어 개발이 아니고 있던 플랫폼에 사용가능한 상태인지 확인하고 적용할 것 )
|
||||
|
||||
- 원래 있던 버튼, 바로가기 등이 없어질 경우 Relation Menu 등을 통해 찾아갈 수 있는 방향으로 함.
|
||||
|
||||
- MCS는 기준정보가 정해지기 전에 레이아웃 모델링을 한다.
|
||||
( 레이아웃을 먼저 그리고 나서야 설비모델링 등록을 할 수 있다 )
|
||||
: 레이아웃 그리는 곳에서 설비를 먼저 등록을 하고 레이아웃에 등록된 데이터를 DB에 있는 실제데이터랑 매핑을 하는 방식임
|
||||
|
||||
- 화면에서 공통적으로 쓰는 버튼같은것들은 템플릿을 동일하게 맞춰주면 좋겠음.
|
||||
Reference in New Issue
Block a user