KR20140061418A

KR20140061418A - 플라즈마 프로세싱 관련 소프트웨어 애플리케이션용 데이터 아키텍처 및 사용자 인터페이스

Info

Publication number: KR20140061418A
Application number: KR1020147004577A
Authority: KR
Inventors: 폴 발린타인; 제이미 사르미엔토; 듀안 스미스; 차드 알. 위트먼
Original assignee: 램 리써치 코포레이션
Priority date: 2011-07-21
Filing date: 2012-07-03
Publication date: 2014-05-21
Also published as: CN103748554A; KR101933743B1; WO2013011401A1; US8713517B2; TW201316254A; CN103748554B; TWI543080B; US20130024012A1

Abstract

플라즈마 프로세싱 관련 애플리케이션을 생성하기 위한 아키텍처가 제공된다. 이 아키텍처는 보안 요소, 데이터 관리 요소 및 사용자 인터페이스 (UI) 요소중 적어도 하나를 포함하는 복수의 프레임워크 요소들을 갖는 기반 층을 포함한다. 이 아키텍처는 뷰들 (views) 의 세트를 갖는 분석 뷰 층으로서, 상기 세트는 상기 기반 층으로부터의 요소들을 사용하여서 생성된, 상기 분석 뷰 층을 더 포함한다. 이 아키텍처는 복수의 분석 모듈－상기 복수의 분석 모듈 각각은 상기 세트 중의 하나 이상의 뷰로부터 어셈블리됨－을 갖는 분석 모듈 층을 더 포함한다. 이 아키텍처는 복수의 애플리케이션－상기 복수의 애플리케이션 각각은 하나 이상의 상기 분석 모듈로부터 어셈블리됨－을 갖는 애플리케이션 층을 포함한다.

Description

플라즈마 프로세싱 관련 소프트웨어 애플리케이션용 데이터 아키텍처 및 사용자 인터페이스{DATA ARCHITECTURE AND USER INTERFACE FOR PLASMA PROCESSING PRLATED SOFTWARE APPLICATIONS}

플라즈마 강화 에칭 및 플라즈마 강화 증착과 같은 플라즈마 강화 프로세싱은 기판 (예를 들어서, 실리콘 웨이퍼, 평면 패널) 을 전자 제품 (예를 들어서, 집적 회로, 평면 패널 디스플레이 또는 액정 디스플레이) 으로 프로세싱하는데 오래 동안 사용되어 왔다. 이렇게 플라즈마 강화 기술을 사용하여서 기판을 처리하는 바는 매우 복잡하여서 매우 숙련된 인력이 복잡한 플라즈마 장비들을 운용하는 경향이 있다. 이러한 플라즈마 강화 프로세싱의 복잡성은 플라즈마 프로세싱 챔버 내에서 발생하는 이벤트를 제어, 모니터링, 분석 및/또는 이에 대응할 수 있는 소프트웨어 애플리케이션을 사용함으로써 경감될 수 있다.

그러나, 현대의 고 디바이스 밀도 (high-device-density) 플라즈마 프로세싱 기술의 복잡성으로 인해서, 대량의 데이터 및 매우 복잡한 소프트웨어 애플리케이션 어레이가 소정의 기판 배치 (batch) 를 플라즈마 프로세싱할 시에 필요하다. 예를 들어서, 상이한 소프트웨어 애플리케이션들이 사용되어서, 웨이퍼 이동을 제어하고, 플라즈마를 개시/중지하며, 특정 레시피를 사용하여서 특정 타입의 플라즈마를 생성하고, 소정의 레시피에 따라서 프로세싱을 실시하도록 다양한 노브 (konb) 를 제어하며, 챔버의 전반적인 상태를 모니터링하고 처리량을 분석하며 알람 (alarm) 을 생성하는 등을 한다.

생산되는 디바이스들의 크기가 점점 줄어들면서 플라즈마 프로세싱 요구 수준이 점점 증가하면서, 심지어 최고로 숙련된 인간 운용자까지도 복잡한 다중 챔버 플라즈마 프로세싱 클러스터를 동작 및 유지 관리하는데 있어서 사용되는 계속적으로 변경되는 소프트웨어 애플리케이션들의 광대한 어레이들을 감당하기 벅찰 수 있다. 이는 부분적으로는 이러한 소프트웨어 애플리케이션들 각각이 제공하는 대량의 특징 및 기능 세트는 이러한 특정 소프트웨어 애플리케이션의 특징 및 기능들을 주목적으로 익힌 다음에야만 오직 액세스되고/되거나 생산적으로 활용될 수 있기 때문이다.

또한, 운용자가 일 특정 소프트웨어 애플리케이션을 완전히 익혔다고 하여도, 기판 플라즈마 프로세싱을 위해서 또한 필요한 다른 소프트웨어 애플리케이션의 특징 및 기능은 상이한 사용자 인터페이스 시각적 체감 (look/feel) 단계 또는 네비게이션 (navigation) 단계를 사용하는 바를 도입하거나 상이한 데이터 제공 방식을 도입하거나 인간 운용자가 소정의 동작을 위해서 필요한 데이터를 취득하는데 있어서 상이한 방식을 도입할 수 있다. 이로써 인간 운용자는 각 개별 플라즈마 프로세싱 관련 소프트웨어 (PPRS : plasma-processing-related software) 애플리케이션의 고유한 사용자 인터페이스 네비게이션 동작 또는 시각적 체감 단계를 학습해야 하고 각 PPRS 애플리케이션의 상이한 데이터 취득 단계들도 익혀야 하기 때문에, 주목적인 훈련이 통상적으로 실시된 후에야만 인간 운용자는 최신의 플라즈마 프로세싱 머신을 효율적으로 운용하기 위해서 필요한 필수 소프트웨어 애플리케이션 슈트 (suite) 를 생산적으로 다룰 수 있다.

현 진행 상황을 감안하면, 예를 들어서 버전 업데이트로 인해서 이러한 애플리케이션 슈트 내의 임의의 소정의 소프트웨어 애플리케이션의 특징 또는 기능 세트가 변경되는 경우에는, 인간 운용자는 이 업데이트된 소프트웨어 애플리케이션에 대하여 새로운 사용자 인터페이스 및/또는 데이터 취득 단계를 재확습해야 한다. 몇몇 인간 운용자들에게는 상기한 애플리케이션 복잡성을 감당하기에 벅차며 새로운 PPRS 애플리케이션을 학습하고자 하는 동기도 없을 수 있거나 기판을 생산하는데 필요한 최소한의 동작을 수행하는데 절대적으로 필요한 수준보다 더 깊은 수준으로 기존의 PPRS 애플리케이션을 연구하고자 하는 동기가 없을 수 있다. 따라서, 현재의 PPRS 애플리케이션의 복잡성으로 인해서 인간 운용자들은 각 PPRS 애플리케이션에 제공될 수 있는 잠재적 풍부한 특징 또는 기능을 실시할 수 없을 수도 있다.

본 발명은 첨부 도면을 참조하여서 예시적이면서 비한정적으로 설명될 것이며 이 첨부 도면에서 유사한 참조 부호는 유사한 요소를 나타낸다.
도 1은 본 발명의 실시예에 따른 예시적인 PPRS 아키텍처를 포함하는 4 개의 층들의 개념도이다.
도 2는 다양한 모듈 인스턴스 (module instance) 및 뷰 인스턴스 (view instance) 가 나타난 애플리케이션의 예시적인 스크린샷 (screenshot) 이다.
도 3은 소정의 일반적인 컨텍스트 (context) 데이터 필드 및 특정 컨텍스트 데이터 필드를 갖는 "데이터 로딩" 패널 (panel) 의 실례를 나타내고 있다.
도 4는 특정 컨텍스트 데이터 차이로 인해서 도 3의 특정 컨텍스트 데이터 필드와 상이한 특정 컨텍스트 데이터 필드를 갖는 "데이터 로딩" 패널의 다른 실례를 나타내고 있다.

이제, 첨부 도면들에서 예시된 바와 같은 본 발명의 몇몇 실시예들을 참조하여서 본 발명이 세부적으로 기술될 것이다. 다음의 설명 부분에서, 다수의 특정 세부 사항들이 본 발명의 철저한 이해를 제공하기 위해서 제시된다. 그러나, 본 발명은 이러한 특정 세부 사항이 전부 또는 일부가 없어도 실시될 수 있음은 본 기술 분야의 당업자에게 자명하다. 다른 경우로서, 잘 알려진 프로세스 단계 및/또는 구조들은 본 발명을 불필요하게 모호하게 하지 않도록 하기 위해서 세부적으로는 기술되지 않을 것이다.

방법 및 기술들을 포함하는 다양한 실시예들이 본 명세서에서 이하에서 기술된다. 본 발명은 본 발명에 따른 기술들의 실시예들을 실행하기 위한 판독 가능한 인스트럭션들이 저장된 컴퓨터 판독 가능한 매체를 포함하는 제조품을 역시 포함할 수 있다. 이러한 컴퓨터 판독 가능한 매체는 예를 들어서 컴퓨터 판독 가능한 코드를 저장할 수 있는 반도체 형태, 자기 형태, 광자기 형태, 광학적 형태 또는 다른 형태의 컴퓨터 판독 가능한 매체를 포함할 수 있다. 또한, 본 발명은 본 발명의 실시예들을 수행할 수 있는 장치를 역시 포함한다. 이러한 장치는 본 발명의 실시예들과 관련된 태스크 (task) 를 실행하도록 전용 및/또는 프로그램된 회로들을 포함할 수 있다. 이러한 장치의 실례들은 적절하게 프로그램된 범용 컴퓨터 및/또는 전용 컴퓨팅 디바이스를 포함하고 본 발명의 실시예들과 관련된 다양한 태스크를 위해서 구성된 전용/프로그램가능한 회로와 컴퓨터/컴퓨팅 디바이스의 조합을 포함할 수 있다.

본 발명의 실시예들은 기판 플라즈마 프로세싱 시에 사용되는 PPRS 애플리케이션 슈트 중의 상이한 PPRS 애플리케션들 간에 일관적인 사용자 인터페이스 네비게이션 동작 및/또는 시각적 체감 및 일관적인 데이터 관리/액세스를 증진시킨다. 또한, 본 발명의 실시예들은 새로운 PPRS 애플리케이션들이 보다 신속하게 개발될 수 있도록 구축 블록 (building block) 이 재사용되는 것을 증진시킬 수 있다. 또한, 개발된 임의의 새로운 PPRS 애플리케이션은 실질적으로 동일한 일관된 사용자 인터페이스 및 실질적으로 동일한 데이터 관리/액세스를 따르도록 함으로써 사용자가 이를 채용하는 바를 촉진시키고 신속한 훈련 및 애플리케이션 전개를 용이하게 한다.

하나 이상의 실시예들에서, 4 개 이상의 층들을 갖는 PPRS 아키텍처가 제공된다. 본 명세서의 실례들에서 기술된 바와 같은 바람직한 실시예에서는, 4 개의 층을 갖는 PPRS 아키텍처가 제공된다. 다른 실시예에서는, 보다 많은 개수의 층을 갖는 PPRS 아키텍터가 필요하다면 사용될 수 있다. 하나 이상의 실시예들에서, 4 개의 층들은 최저 레벨로부터 최고 레벨까지 기반 층 (foundation layer), 분석 뷰 층 (analysis view layer), 분석 모듈 층 및 애플리케이션 층의 순서로 되어 있다.

최저 레벨에 있는 기반 층은 분석 뷰 층 내의 뷰들이 공통적으로 사용하는 프레임워크 아이템들을 포함한다. 이 기반 층의 다음의 상위 레벨에 있는 분석 뷰 층은 상기 기반 층 내의 공통 프레임워크 아이템 세트를 레버리지하는 (leveraging) (예를 들어서, 상기 아이템 세트를 액세스하거나 사용하거나 아이템 세트에 의해서 규정되는) 다양한 뷰들 (페이지들) 을 포함한다. 이 분석 뷰 층의 다음의 상위 레벨에 있는 분석 모듈 층은 분석 뷰 층 내의 공통 분석 뷰 세트를 레버리지하는 (예를 들어서, 상기 분석 뷰 세트를 액세스하거나 사용하거나 분석 뷰 세트에 의해서 규정되는) 다양한 모듈들을 포함한다. 상이한 분석 뷰 조합들이 사용되어서 하나 이상의 분석 모듈을 생성할 수 있다. 마지막으로, 이 분석 모듈 층의 다음의 상위 레벨에 있는 애플리케이션 층은 분석 모듈 층 내의 공통 분석 모듈 세트를 레버리지하는 (예를 들어서, 상기 분석 모듈 세트를 액세스하거나 사용하거나 분석 모듈 세트에 의해서 규정되는) 다양한 애플리케이션들을 포함한다. 상이한 분석 모듈 조합들이 사용되어서 하나 이상의 애플리케이션을 생성할 수 있다.

더 자세하게 살펴보면, 기반 층 내에서는, 저 레벨 보안, 저 레벨 데이터 관리/액세스 및 저 레벨 UI (사용자 인터페이스) 네비게이션 동작 및 시각적 체감 또는 시각화를 다루는 프레임워크 아이템들이 제공된다. 이러한 프레임워크 아이템들은 예를 들어서 상이한 뷰들 또는 페이지들이 어떻게 보이는지 어떻게 네비게이션되는지 또는 데이터를 어떻게 액세스 및 관리하는지를 지배한다. 이어서, 상이한 뷰들 또는 페이지들이 이 기반 층 내의 이러한 프레임워크 아이템들에 의해서 규정된 사용자 인터페이스 및 데이터 액세스/관리 규칙을 따라서 다양한 조합으로 해서 조합될 수 있다. 상이한 분석 모듈들이 동일한 사용자 인터페이스 및 데이터 액세스/관리 규칙 세트를 따르고 동일한 공통 분석 뷰 세트를 레버지기하기 때문에, 새로운 분석 모듈을 개발할 시에 분석 뷰 재사용성이 증진되게 된다. 또한, 인간 운용자가 특정 페이지/뷰를 네비게이션하는 방식 또는 특정 페이지/뷰를 통해서 데이터를 액세스/관리하는 방식을 한번 학습하면, 상이한 모듈에서 동일한 페이지/뷰가 사용될 때에는 실질적으로 동일한 UI 시각적 체감 단계 및 네비게이션 단계가 체험되어질 수 있다. 이로써, 운간 운용자가 새로운 모듈을 만나게 될 때에 학습 상의 복잡성은 실질적으로 최소화되게 된다.

더 나아가, 이어서, 기반 층 내의 프레임워크 아이템들에 의해서 규정된 사용자 인터페이스 및 데이터 액세스/관리 규칙 세트를 따라서 상이한 모듈들이 다양한 조합으로 해서 조합되어서 상이한 애플리케이션들을 생성한다. 상이한 애플리케이션들이 동일한 사용자 인터페이스 및 데이터 액세스/관리 규칙 세트를 따르고 동일한 공통 분석 모듈 세트를 레버지기하기 때문에, 새로운 애플리케이션을 개발할 시에 분석 모듈 재사용성이 증진되게 된다. 또한, 인간 운용자가 특정 모듈을 네비게이션하는 방식 또는 특정 모듈을 통해서 데이터를 액세스/관리하는 방식을 한번 학습하면, 상이한 애플리케이션에서 동일한 모듈이 사용될 때에는 실질적으로 동일한 UI 시각적 체감 단계 및 네비게이션 단계가 체험되어질 수 있다. 이로써, 운간 운용자가 새로운 애플리케이션을 만나게 될 때에 학습 상의 복잡성은 실질적으로 최소화되게 된다.

또한, 프레임워크는 모든 애플리케이션에 대해서 공통되는 아이템들을 제공할 수 있다. 달리 말하면, 프레임워크 컨네이터 (framework container) 가 제공되며 이 프레임워크 컨테이너 UI 및 데이터 액세스/관리는 (이러한 프레임워크 컨테이너 UI 단계 및 프레임워크 컨테이너 데이터 액세스/관리 단계가 애플리케이션 슈트 중의 다양한 애플리케이션 간에서 공통된다고 가정하면) 애플리케이션 슈트 내에서 어느 애플리케이션이 제공되는지의 여부와 상관 없이 일관적으로 유지될 수 있다. 이로써, 애플리케이션 슈트가 어느 애플리케이션들에 의해서 점유되는지 또는 얼마나 많은 애플리케이션이 애플리케이션 슈트를 점유하고 있는지 또는 어느 애플리케이션이 현재 주목되고 있는지에 상관 없이 이 애플리케이션 슈트에 대해서는 실질적으로 동일한 UI 시각적 체감 단계 및 실질적으로 동일한 데이터 관리/액세스 단계가 인간 운용자에게 제공될 수 있다.

다양한 실시예들의 특징 및 장점들이 다음의 도면 및 설명을 참조하면 보다 잘 이해될 것이다.

도 1은 본 발명의 실시예에 따른 예시적인 PPRS 아키텍처 (100) 를 포함하는 4 개의 층들의 개념도로서, 이 예시적인 PPRS 아키텍처 (100) 는 애플케이션 슈트 내의 모든 PPRS 애플리케이션 간에서 일관된 UI 및 일관된 데이터 관리 및 액세스를 제공하고 재사용성을 증진시킨다. 도 1에서는, 복수의 프레임워크 아이템 (104 내지 112) 을 포함하는 기반 층 (102) 이 도시되어 있다. 도 1의 이 복수의 프레임워크 아이템 (104 내지 112) (보안 아이템 (104), 데이터 타입 아이템 (106), 데이터 관리 아이템 (108), GUI 기반 아이템 (110), 데이터 시각화 아이템 (112)) 은 이 아이템들을 3 개의 광범위한 카테고리 (보안 카테고리, 데이터 액세스/관리 카테고리 및 UI 카테고리) 로 해서 포함하고 있다.

예를 들어서, 보안 프레임워크 아이템 (104) 은 보안 규정 사항을 포함하고 사용자들에 의한 승인 액세스 및 프리빌지지 (privilege) 를 지배할 수 있다. 데이터 액세스/관리 카테고리는 2 개의 프레임워크 아이템, 즉 데이터 타입 아이템 (106) 및 데이터 관리 아이템 (108) 을 포함한다. 데이터 타입 아이템 (106) 은 다양한 뷰들 및 모듈들이 일관된 방식으로 데이터를 액세스할 수 있도록 툴들로부터의 데이터 규정 사항들을 포함할 수 있다. 데이터 관리 아이템 (108) 은 데이터가 저장된 위치, 다양한 데이터 저장 위치에서 데이터가 포맷되는 방식 및 다양한 데이터 저장 위치가 액세스되는 방식을 규정할 수 있다.

UI 프레임워크 아이템은 GUI (그래픽 유저 인터페이스) 기반 프레임워크 아이템 (110) 및 데이터 시각화 프레임워크 아이템 (112) 을 포함할 수 있다. GUI 기반 프레임워크 아이템 (110) 은 GUI 기반 프레임워크 아이템 (110) 과 연관된 규정 사항 및 규칙을 레버리지하는 뷰들/모듈들/애플리케이션들/프레임워크에 의한 일관된 UI 시각적 체감 및/또는 네비게이션 동작을 지원하는 UI 규정 사항 및 규칙을 포함할 수 있다. 데이터 시각화 프레임워크 아이템 (112) 은 차트 툴, 테이블 툴, 등과 같은 데이터 시각화 툴을 포함할 수 있다.

기반 층 (102) 상위에는 분석 뷰 층 (120) 이 존재한다. 분석 뷰 층 (120) 은 기반 층 (102) 내의 프레임워크 아이템들에 의해서 특정되는 규정 사항/규칙/방법들을 사용하여서 생성되는 뷰들 (디스플레이 스크린 상에서는 페이지들로서 나타날 수 있음) 을 포함한다. 따라서, 분석 뷰 층 (120) 의 뷰들 (122 내지 140) (이벤트 뷰 (122), 알람 뷰 (124), 로트 (lot) 뷰 (126), 차트 뷰 (128), 차트 구성 뷰 (130), 처리량 뷰 (132), 히스토그램 뷰 (134), 트렌딩 (trending) 뷰 (136), 웨이퍼 이동 뷰 (138), 챔버 상태 인덱스 뷰 (140)) 는 동일한 UI 시각적 체감 및 네비게이션 동작을 갖는데 그 이유는 이들이 GUI (그래픽 유저 인터페이스) 기반 프레임워크 아이템 (110) 및 데이터 시각화 프레임워크 아이템 (112) 에 의해서 특정된 바와 동일한 규정 사항/규칙/방법을 사용하여서 아이템들을 레버리지하기 때문이다. 또한, 분석 뷰 층 (120) 의 뷰들 (122 내지 140) 은 동일한 데이터 관리/액세스/로딩 단계 및 방법을 갖는데 그 이유는 데이터 타입 아이템 (106) 및 데이터 관리 아이템 (108) 에 의해서 특정된 바와 동일한 규정 사항/규칙/방법을 사용하여서 아이템들을 레버리지하기 때문이다. 분석 뷰 층 (120) 의 하나 이상의 뷰들 (122 내지 140) 에 대해서 보안이 실시되면, 분석 뷰 층 (120) 의 뷰들 (122 내지 140) 이 보안 아이템 (104) 에서 규정된 바와 동일한 규정 사항/규칙/방법을 사용하여서 아이템들을 레버리지하기 때문에 보안도 일관되게 실시될 수 있다.

도 1의 실례에서, 알람 뷰 (124) 가 사용되어서 알람 명세 파라미터 (alarm specification parameter) 를 획득하고 알람 경보가 필요한 상태가 발생하면 알람을 표시한다. 로트 뷰 (lot view) (126) 는 인간 운용자로 하여금 웨이퍼 로트 정보를 검토하게 한다. 차트 뷰 (128) 는 특정된 차트에 따라서 그래픽 방식으로 데이터를 표시한다. 웨이퍼 이동 뷰 (138) 는 플라즈마 프로세싱 툴들의 다양한 프로세싱 모듈 내로의 웨이퍼 반입 및 외부로의 웨이퍼 반출과 관련된 데이터를 표시한다. 이러한 바들은 오직 실례일 뿐이며 분석 뷰 층 (120) 내의 뷰들 (122 내지 120) 의 다른 실례들이 본 명세서에서 나중에 본 발명에 따른 PPRS 아키텍처의 이점을 이해하는 바를 돕기 위한 실례들을 논의할 때에 세부적으로 논해질 것이다.

이 분석 뷰 층 (120) 상위에 분석 모듈 층 (150) 이 존재한다. 분석 모듈 각각 (이벤트 모듈 (152), 알람 모듈 (154), 처리량 모듈 (156), 웨이퍼 이동 모듈 (158), 챔버 상태 인덱스 모듈 (160)) 은 분석 뷰 층 (120) 의 하나 이상의 뷰들 (122 내지 140) 이 조합되어 생성된다. 이 분석 뷰 층 (120) 중의 뷰는 분석 모듈 층 (150) 중의 단일 분석 모듈에 의해서 독점적으로 사용되거나 분석 모듈 층 (150) 중의 복수의 상이한 분석 모듈들에 의해서 사용될 수 있다. 일 실례에서, 챔버 상태 인덱스 뷰 (140) 는 오직 챔버 상태 인덱스 모듈 (160) 에 의해서만 사용된다. 다른 실례로서, 웨이퍼 이동 뷰 (138) 는 웨이퍼 이동 모듈 (158) 및 처리량 모듈 (156) 양자에 의해서 사용된다.

분석 모듈 층 (150) 상위에 애플리케이션 층 (170) 이 존재한다. 각 애플리케이션 (LamScope Standard 애플리케이션 (172), LamScope Expert 애플리케이션 (174), 알람 브라우저 애플리케이션 (176), APECS Offline 애플리케이션 (178)) 은 분석 모듈 층 (150) 중의 하나 이상의 분석 모듈 (152 내지 160) 을 조합하여서 생성된다. 이 분석 모듈 층 (150) 중의 분석 모듈은 애플리케이션 층 (170) 중의 단일 애플리케이션에 의해서 독점적으로 사용되거나 애플리케이션 층 (170) 중의 복수의 상이한 애플리케이션들에 의해서 사용될 수 있다. 일 실례로서, LamScope Standard 애플리케이션 (172) 은 이벤트 모듈 (152), 알람 모듈 (154) 및 웨이퍼 이동 모듈 (158) 의 조합을 사용할 수 있다. 다른 실례로서, LamScope Expert 애플리케이션 (174) 은 모듈들의 조합, 말하자면 이벤트 모듈 (152), 알람 모듈 (154) 및 처리량 모듈 (156) 의 조합을 사용할 수 있다. 또 다른 실례로서, APECS Offline 애플리케이션 (178) 은 오직 챔버 상태 인덱스 모듈 (160) 만을 사용할 수 있다. 또 다른 실례에서, 알람 브라우저 애플리케이션 (176) 은 오직 알람 모듈 (154) 만을 사용할 수 있다.

(애플리케이션 층 (170) 내의) 애플리케이션들은 모듈 기반의 (modular) 분석 모듈들 (분석 모듈 층 (150) 내에 존재함) 로부터 구축되고 또한 이 분석 모듈들도 역시 모듈 기반의 분석 뷰들 (분석 뷰 층 (120) 내에 존재함) 로부터 구축되며 또한 이 분석 뷰들은 기반 층 (102) 내의 동일한 프레임워크 아이템 세트를 레버리지하기 (예를 들어서, 이 아이템 세트에 액세스하거나 이를 사용하거나 아이템 세트에 의해서 규정되기) 때문에, 어느 모듈(들)에서 분석 뷰가 사용되는지에 상관 없이 동일한 분석 뷰에는 일관된 UI 시각적 체감 (look/feel) 및 네비게이션 동작이 존재하게 된다. 또한, 상술한 구조로 인해서, 분석 모듈이 어느 애플리케이션에 의해서 사용되는지에 상관 없이 동일한 분석 모듈에도 일관된 UI 시각적 체감 및 네비게이션 동작이 존재하게 된다.

또한, 모든 뷰/모듈/애플리케이션에서의 데이터 관리/액세스/로딩은 기반 층 (102) 내의 동일한 프레임워크 아이템 세트를 사용하여서 레버리지하기 때문에, 특정 뷰가 어느 모듈에서 사용되는지와 상관 없이 그리고 특정 모듈이 어느 애플리케이션에서 사용되는지와 상관 없이 데이터는 애플리케이션들 간에서, 모듈들 간에서 그리고 뷰들 간에서 동일한 방식으로 액세스 및 관리될 수 있다.

또한, 뷰들이 동일한 프레임워크 아이템 풀 (pool) 을 사용하여서 레버리지하고 모듈들은 동일한 뷰 풀을 사용하여서 레버리지하고 애플리케이션들도 역시 동일한 모듈 풀을 사용하여서 레버리지하기 때문에, 재사용성이 크게 증진된다.

또한, 데이터 액세스/관리 및 UI 규정 사항/규칙/방법은 모든 애플리케이션들에 대해 공통적인 보편적 (global) 툴들을 지배한다. 이러한 보편적 툴들의 실례들은 모든 애플리케이션들 간에 공통되는 "데이터 로딩", 데이터 저장" 및 "데이터 삭제"를 포함한다. 따라서, 인간 운용자가 애플리케이션 슈트 중의 애플리케이션들 간을 스위칭할 때에, 뷰들/모듈들/애플리케이션들이 실질적으로 동일한 UI 시각적 체감 및 네비게이션 동작 및 실질적으로 동일한 데이터 액세스/관리를 가질 뿐만 아니라, 역시 임의의 소정의 시점에서 인간 운용자에 의해서 어느 애플리케이션이 사용되게 될지에 상관 없이 동일한 보편적 툴 세트도 또한 일관되게 된다.

재사용성의 다른 측면은 새로운 애플리케이션들이 개발될 수 있는 경우이다. 새로운 데이터 타입이 툴들 중 하나에 의해서 생성되고 사용 가능하다고 가정해보자. 이 새로운 데이터 타입을 액세스 및 분석하기 위해서 뷰가 제공되면, 새로운 애플리케이션 개발자는 이 새로운 데이터 타입을 어떻게 액세스하고 분석할지를 이해할 필요가 없다. 이 경우에, 개발자는 이 뷰를 사용하는 적합한 모듈을 단지 사용하기만 하면 되고 이 개발자는 데이터 액세스 및 관리 세부 사항들을 몰라도 된다. 물론, 상이한 목적을 위한 상이한 분석 모듈에서도 역시 동일한 뷰가 사용될 수 있으며 동일한 뷰가 동일한 새로운 애플리케이션 또는 필요하다면 다른 상이한 애플리케이션에서 사용될 수 있다.

대조적으로, 종래 기술의 통상적인 애플리케이션들에서는, 개발자가 사용자 인터페이스를 아무런 사전 지식 없이 통상 신경을 써가며 보고 느끼고 네비게이션해야 하며 가장 기본적인 데이터 관리/액세스 수준에서 데이터를 액세스하고 관리하는 방식을 이해해야만 한다. 소정의 UI 부분 및 데이터 액세스/관리 루틴이 다른 기존의 애플리케이션을 위해서 이미 개발되었다면, 이러한 것들을 재사용하는 바는 불가능할 수 있는데, 그 이유는 다른 상이한 애플리케이션들은 과거에 상이한 애플리케이션 개발 환경 하에서 개발되었기 때문이다 (예를 들어서, C++ 개발 환경에서는 자바 차트 (Java chart) 가 사용될 수 없다). 본 발명의 하나 이상의 실시예들에서, 본 발명에 따른 PPRS 아키텍처의 뷰들/모듈들/애플리케이션들은 C# 프로그래밍 언어 및 미국 워싱턴 레드몬드 소재의 Microsoft 사를 포함하는 다양한 벤더들로부터 입수 가능한 .NET 프레임워크 개발 환경을 사용하여서 개발된다. PPRS 슈트의 모든 뷰들/모듈들/애플리케이션들 간에서 일관되게 사용될 수 있기만 하면, 역시 다른 프로그래밍 언어 및 다른 개발 환경들이 사용될 수 있다.

또한, 뷰들/모듈들/애플리케이션들 모두가 기반 층 내의 동일한 프레임워크 아이템들을 사용하여서 레버리지하기 때문에, 지역화 (localization) 및 업그레이드가 효율적으로 달성될 수 있다. 예를 들어서, 특정 PPRS 애플리케이션이 특정 국가로 지역화될 필요가 있다면, 이 PPRS 애플리케이션이 사용하는 프레임워크 아이템들은 지역화 요구 사항에 맞게 수정될 수 있으며 결과적으로 모든 뷰들/모듈들/애플리케이션들이 자동으로 지역화되게 된다.

도 2는 처리량 모듈 (도 1의 참조 부호 (156)) 의 인스턴스 (instance) 및 알람 모듈 (도 1의 참조 부호 (154)) 의 인스턴스가 런칭된 (launched) 애플리케이션 (본 경우에서는 LamScope Expert 애플리케이션 (도 1의 참조 부호 (174))) 의 예시적인 스크린샷이다. 보다 구체적으로, 알람 모듈 (도 1의 참조 부호 (154)) 의 알람 뷰 (도 1의 참조 부호 (124)) 가 도 2에서 현재 주목되고 있다.

도 2의 전경 (foreground) 의 알람 뷰를 구현하는 페이지에서는, 2 개의 위젯 (210, 212) 이 도시되어 있다. 위젯 (210) 은 알람 데이터 쿼리 (query) 구성을 특정하는데 사용되며, 위젯 (212) 은 알람들을 표시하는데 사용된다. 이 2 개의 위젯 (210, 212) 에 대한 UI 시각적 체감은 도 1의 UI 프레임워크 아이템 (110, 112) 에 의해서 지배된다.

알람 모듈 (202) (비교를 위해서 도 1의 참조 부호 (154) 를 참조 바람) 의 다양한 뷰들이 탭들 (220, 222, 224, 226) 에 의해서 구현된다. 따라서, 탭 (220) (알람) 은 도 1의 아키텍처의 알람 뷰 (124) 에 대응한다. 탭 (222) (차트) 은 도 1의 아키텍처의 차트 뷰 (128) 에 대응한다. 탭 (224) (로트) 은 도 1의 아키텍처의 로트 뷰 (126) 에 대응한다. 탭 (226) (차트 구성) 은 도 1의 아키텍처의 차트 구성 뷰 (130) 에 대응한다. 탭들 (220, 222, 224, 226) 중 하나를 선택함으로써, 인간 운용자는 소정의 시간에 주목되는 알람 모듈 (202) 의 뷰를 선택할 수 있다. 또한, 알람 모듈 (202) 이 상이한 애플리케이션에서 구현되면, 상술한 바와 동일한 탭들 및 위젯들이 실질적으로 동일하게 나타날 것이며, UI 네비게이션 단계도 실질적으로 동일하게 구현될 것이다. 마찬가지로, 알람 모듈 (202) 의 뷰들에 의한 데이터 액세스/관리도 실질적으로 동일한 방식으로 구현될 것이다. 따라서, 일 애플리케이션에서 소정의 모듈을 통해서 인간 운용자가 획득한 체험 및 지식으로 인해서, 인간 운용자가 다른 상이한 애플리케이션에서 동일한 모듈과 상호 작용할 때에 능숙하게 이를 다룰 수 있게 된다.

도 2의 LamScope Expert 애플리케이션의 다양한 모듈들은 도 2의 아이콘들 (240, 242 및 244) 을 통해서 액세스될 수 있다. 이 3 개의 아이콘은 도 1의 LamScope Expert 애플리케이션 (174) 을 구성하는 도 1의 3 개의 모듈들 (152, 154 및 156) 에 대응한다. 인간 운용자가 아이콘 (240) 을 선택했기 때문에 알람 모듈이 주목되고 있다. 다른 모듈을 주목하기 위해서, 인간 운용자는 그에 대응하는 아이콘을 선택하기만 하면 된다. 이러한 아이콘들에 대한 시각적 체감도 역시 도 1을 참조하여서 기술된 UI 프레임워크 아이템들에 의해서 지배되며, 인간 운용자가 하위 좌측 코너 (아이콘 위치는 애플리케이션들 간에 일관되기만 하면 임의적으로 설정될 수 있으며, 위치 선택은 그렇게 중요한 바가 아님) 에서 적합한 아이콘을 선택함으로써 임의의 소정의 애플리케이션의 모듈들에 액세스할 수 있도록 그 시각적 체감이 애플리케이션들 간에 일관된다.

보편적 툴 아이콘 (260, 262 및 264) ("데이터 로딩", "데이터 저장" 및 "데이터 삭제") 이 도 2에 도시되어 있다. 일반적으로 말하면, 이러한 보편적 툴 아이콘들은 보다 광범위한 프레임워크의 일부이며 애플리케이션들 간에서 공통되며 애플리케이션들 간에 일관된 시각적 체감 및 네비게이션 동작을 갖는 보편적 툴들을 구현한다. 이러한 보편적 툴 아이콘들에 대한 시각적 체감은 도 1을 참조하여서 기술한 UI 프레임워크 아이템들에 의해서 지배되며, 인간 운용자가 상위 좌측 코너 (보편적 툴 아이콘 위치는 애플리케이션들 간에 일관되기만 하면 임의적으로 설정될 수 있으며, 위치 선택은 그렇게 중요한 바가 아님) 에서 적합한 아이콘을 선택함으로써 임의의 소정의 애플리케이션을 다루는 동안에 이러한 보편적 툴들을 용이하게 액세스할 수 있도록 그 시각적 체감이 애플리케이션들 간에 일관된다.

도 3은 (예를 들어서, 도 2의 "데이터 로딩" 아이콘 (260) 을 활성화시킴으로써) 활성화되는 "데이터 로딩" 보편적 툴의 실례를 나타내고 있다. 본 특정 실례에서, 인간 운용자가 LamScope Expert 애플리케이션 내의 알람 분석 모듈을 다루고 있을 동안에 데이터 로딩 패널이 나타나고 있는 중이다. PPRS 아키텍처의 다른 요소들에 대한 UI 시각적 체감 및 네비게이션 동작과 유사한, 이 데이터 로딩 패널에 대한 UI 시각적 체감 및 네비게이션 동작은 일관된 사용자 인터페이스 체험이 가능하도록 도 1의 UI 프레임워크 아이템들 (110,112) 에 의해서 지배된다. 도 3의 데이터 로딩 패널에 의한 데이터 관리 및 액세스는 데이터 액세스 및 관리가 표준화되도록 도 1의 데이터 관리/액세스 프레임워크 아이템 (106, 108) 을 사용하여서 레버리지한다.

데이터 로딩 툴에 제공되는 컨텍스트 정보는 데이터 로딩 패널이 인간 운용자가 현재 다루고 있는 특정 모듈/애플리케이션에서 적절하게 점유되도록 한다. 도 3의 데이터 로딩 패널은 상이한 애플리케이션에서도 재사용될 수 있다. 그러나, 상이한 애플리케이션과 관련된 컨텍스트 정보는 상이하기 때문에, (실질적으로 유사한 UI 시각적 체감 및 네비게이션 동작 및 실질적으로 유사한 데이터 관리 및 액세스 방법을 사용할지라도) 상이한 필드들이 데이터 로딩 패널의 소정의 서브섹션들을 점유하게 된다.

일반적으로 말하자면, 특정 페이지 내에 점유된 필드들을 지배하는 적어도 2 개의 타입의 컨텍스트 정보가 존재한다. 일반적 컨텍스트 정보는 어느 특정 뷰/모듈/애플리케이션이 현재 주목되고 있는지와 상관없이 존재하는 필드들을 특정한다. 이러한 일반적인 컨텍스트 데이터 필드의 실례들은 툴 ID, 데이터 생성 시간 등을 포함한다. 이와 대조하여서, 특정 컨텍스트 정보는 페이지가 나타날 때에 주목되고 있는 뷰/모듈/애플리케이션과 관련하여서 점유되는 필드들을 특정한다. 예를 들어서, 알람 분석 모듈이 현재 주목되고 있으므로 특정 컨텍스트 필드는 (예를 들어서, 알람을 발행하는 툴 또는 센서가 갖는) 알람 ID와 같은 알람 분석과 관련된다.

따라서, (일반적이든 특정적이든) 컨텍스트 정보는 표시되는 필드를 지배하고 이러한 필드와 연관된 속성들을 다루는 제어 사항들을 지배한다. 본 발명의 하나 이상의 실시예들에서, 일반적인 컨텍스트 정보와 연관된 필드들은 페이지 내에서 일반적으로 구획된 구역에 있는 위젯 내에서 표시되는 반면에, 특정 컨텍스트 정보와 연관된 필드들은 이 페이지의 다른 일반적으로 구획된 구역에 있는 다른 위젯 내에서 표시된다.

더 구체적으로 말하자면, 도 3의 실례에서, LamScope Expert 애플리케이션의 알람 분석 모듈이 현재 주목되고 있으므로, 특정 컨텍스트 위젯 (302) 이 이 특정 컨텍스트에 의존하는 필드들을 표시하고 있다. 이와 대조하여서, 위젯 (304) 은 어느 뷰/모듈/애플리케이션이 현재 주목되는지와 상관없이 언제나 불변인 필드들을 표시하고 있다. LamScope Expert 애플리케이션의 알람 분석 모듈이 현재 주목되고 있으므로, 도 3의 데이터 로딩 패널은 이후에 선택될 4 개의 가능한 데이터 소스 선택 사항들 (310, 312, 314, 316) 을 표시하고 있다. 일 실시예에서, 전력이 들어오면 수행되거나 주기적으로 수행되는 자동 파악 (auto-discovery) 동작이 수행되어서 예를 들어서 알람 데이터를 포함하는 데이터 소스들의 개수 및 ID를 파악한다.

이제, 도 3의 데이터 로딩 패널과 도 4의 데이터 로딩 패널을 서로 비교 대조해보자. 도 4의 실례에서, 데이터 로딩 패널은 도 3의 일반적 컨텍스트 위젯 (304) 내에 표시된 필드들과 동일한 필드를 그의 일반적 컨텍스트 위젯 (404) 내에서 표시하고 있다. 이는 도 3의 위젯 (304) 및 도 4의 위젯 (404) 과 연관된 필드들은 일반적 컨텍스트 필드이며 현재 주목되고 있는 특정 뷰/모듈/애플리케이션에 의존하지 않기 때문이다. 그러나, 특정 컨텍스트 위젯 (402) 은 도 3의 특정 컨텍스트 위젯 (302) 내에 표시된 필드들과는 상이한 필드들을 표시하고 있는데 그 이유는 상이한 모듈 (도 4의 경우에서는 처리량 모듈) 이 주목되고 있는 동안에 도 4의 데이터 로딩 패널이 나타나기 (called up) 때문이다. 또한, 특정 컨텍스트 정보는 도 4의 데이터 로딩 패널이 오직 3 개의 소스 (412,414,416) 만을 처리량 데이터를 획득하기 위한 가능한 데이터 소스 선택 사항들로서 특정하게 하고 있다.

또한, 도 3의 데이터 로딩 패널과 도 4의 데이터 로딩 패널이 해당 데이터 패널을 활성화되게 하는 컨텍스트들이 서로 상이하기 때문에 서로 상이한 필드들을 포함할지라도, 사용자 인터페이스 시각적 체감 사항은 대부분 동일하게 유지되는데 그 이유는 이 사용자 인터페이스가 기반 층 내의 동일한 UI 프레임워크 아이템들을 사용하여서 동일한 규칙에 의해서 실현되기 때문이다. 따라서, 데이터 소스를 선택하기 위한 아이콘의 형상은 전반적으로 동일하게 보이며, 이러한 아이콘들은 데이터 소스 아이콘의 개수가 변할지라도 상이한 데이터 로딩 패널들 내에서 동일한 일반적 위치에 배치된다. 다른 실례로서, 도 3의 일반적 컨텍스트 위젯 (304) 내의 필드들 및 도 4의 일반적 컨텍스트 위젯 (404) 내의 필드들은 실질적으로 동일하게 보이는데 그 이유는 이러한 데이터 필드들은 현재 주목되고 있는 특정 뷰/모듈/애플리케이션과 상관 없이 불변하기 때문이다. 또한, 이러한 필드들과 관련된 속성들을 다루기 위한 제어 사항들도 역시 도 3 및 도 4에서 동일하게 보일 수 있다. 또 다른 실례로서, 특정 컨텍스트 데이터 필드들이 도 3과 도 4 간에서 서로 상이하지만 (도 3에서는 참조 부호 (302) 이며 도 4에서는 참조 부호 (402) 임), 이러한 필드들의 일반적인 위치 (예를 들어서, 일관되게 페이지의 우측 위치이지만, 이러한 위치 선택은 변할 수 있음) 는 양 도면에서 실질적으로 동일하며 이로써 가능한한 일관된 사용자 인터페이스 시각적 체감이 실현될 수 있다.

전술한 바로부터 이해할 수 있는 바와 같이, 본 발명의 실시예를 따라서, 일관된 사용자 인터페이스 (UI) 시각적 체감 및 네비게이션 동작이 실현되며, 이로써, 인간 운용자가 PPRS 슈트의 소정의 애플리케이션을 다룰 때에 이 슈트의 다른 애플리케이션들 내의 유사한 뷰들 및/또는 유사한 모듈들을 이미 사용하였다면 이 소정의 애플리케이션을 더 효율적이면서 생산적으로 다룰 수 있게 된다. 이렇게 복수의 모듈들 간 또는 애플리케이션들 간에서 사용자 인터페이스를 일관되게 시각적으로 체감하고 네비게이션할 수 있음으로 인해서 인간 운용자가 새로운 PPRS 애플리케이션을 만나게 되면 이를 학습하는 수고를 크게 줄일 수 있다.

최저 레벨 (즉, 기반 층) 에서 사용자 인터페이스 시각적 체감 및 네비게이션을 실현함으로써, 유리하게는 모든 뷰들/모듈들/애플리케이션들이 이 기반 층 내의 프레임워크 아이템들에 의해서 특정된 규정 사항/규칙/방법을 따를 수 있다. 이로써, 이 기반 층 내의 프레임워크 아이템들에 의해서 특정된 규정 사항/규칙/방법을 간단하게 변경함으로써, 사용자 인터페이스와 관련된 변경이 용이하게 이루어질 수 있으며 그 변경 사항들이 상이한 뷰들/모듈들/애플리케이션들 간에 일관되게 전달될 수 있다.

또한, 뷰들, 모듈들 및 애플리케이션들이 그 아래의 층들 내의 개체들을 서로 조합함으로써 모듈 기반 방식으로 구축되기 때문에, 데이터 액세스/관리 애브스트랙션 (abstraction) 이 달성되며, 데이터 액세스/관리 그 자체가 뷰들/모듈들/애플리케이션들 간에 통일되며 구축 블록들을 재사용하는 정도가 높아지게 된다. 따라서, 기존의 모듈/뷰/프레임워크 아이템을 사용하여서 새로운 애플리케이션이 효율적으로 개발될 수 있으며 이로써 오늘날 계속 진화하면서 점점 보다 엄격해지고 있는 프로세스 요구 사항들을 수용하는데 필요한 다양한 플라즈마 장비 시스템들을 운용 및 관리하는 소프트웨어 툴들을 구현하는 비용이 크게 저감된다.

본 발명이 몇몇 바람직한 실시예들과 관련하여서 기술되었지만, 본 발명의 범위 내에 포함되는 다양한 대체, 치환, 균등 사항 등이 존재한다. 또한, 본 발명의 방법 및 장치를 구현하는 다수의 다른 방식들이 존재할 수 있다. 다양한 실례들이 본 명세서에서 제공되었지만, 이러한 실시예들은 단지 예시적이면서 비한정적일 뿐이며 본 발명을 한정하는 것은 아니다.

또한, 발명의 명칭 및 발명의 내용 부분은 본 명세서에서 편이성을 위해서 제공되었을 뿐 본 발명의 청구 범위를 해석하는데 사용되어서는 안된다. 또한, 요약 부분이 매우 짧게 기술되지만 이도 역시 편이성을 위한 것일 뿐 본 발명의 범위를 해석하거나 한정하는데 사용되지 말아야 하며, 본 발명의 범위는 청구 범위에서 명시되고 있다. 용어 "세트"가 본 명세서에서 사용되면, 이 용어는 제로, 하나 또는 2 개 이상의 요소들을 포함하도록 자신의 통상적으로 이해되는 수학적 의미를 갖는 것으로 해석된다. 따라서, 다음의 청구 범위는 본 발명의 진정한 사상 및 범위 내에 포함되는 모든 치환, 대체 및 균등 사항을 포함하는 것으로 해석되어야 한다.

Claims

플라즈마 프로세싱 관련 애플리케이션을 생성하기 위한 아키텍처로서,
보안 요소, 데이터 관리 요소 및 사용자 인터페이스 (UI) 요소 중 적어도 하나를 포함하는 복수의 프레임워크 요소들을 갖는 기반 층;
뷰들 (views) 의 세트를 갖는 분석 뷰 층으로서, 상기 뷰들의 세트는 상기 기반 층으로부터의 요소들을 사용하여서 생성된, 상기 분석 뷰 층;
복수의 분석 모듈－상기 복수의 분석 모듈 각각은 상기 뷰들의 세트 중 하나 이상의 뷰로부터 어셈블리 (assemble) 됨－을 갖는 분석 모듈 층; 및
복수의 애플리케이션－상기 복수의 애플리케이션 각각은 하나 이상의 상기 분석 모듈로부터 어셈블리됨－을 갖는 애플리케이션 층을 포함하는,
아키텍처.
제 1 항에 있어서,
상기 프레임워크 요소는 적어도 보안 규정 사항들을 포함하는 상기 보안 요소를 포함하는,
아키텍처.
제 1 항에 있어서,
상기 프레임워크 요소는,
적어도 툴들의 세트로부터의 데이터 규정 사항을 포함하는 데이터 타입; 및
적어도 저장된 데이터의 위치, 저장된 데이터의 포맷 및 저장된 데이터를 액세스하기 위한 수단을 포함하는 데이터 관리 항목 중,
적어도 하나를 포함하는 상기 데이터 관리 요소를 포함하는,
아키텍처.
제 1 항에 있어서,
상기 프레임워크 요소는,
사용자 인터페이스 규정 사항 및 규칙 중 적어도 하나를 포함하는 그래픽 유저 인터페이스 (GUI) 요소; 및
차트 및 테이블 (table) 중 적어도 하나를 포함하는 데이터 시각화 요소 중,
적어도 하나를 포함하는 상기 사용자 인터페이스 요소를 포함하는,
아키텍처.
제 1 항에 있어서,
상기 뷰들의 세트는 디스플레이 스크린 상의 페이지들의 세트로서 제공되며,
상기 뷰들의 세트 중의 각 뷰는,
일관된 네비게이션 모드를 갖는 일관된 사용자 인터페이스;
일관된 데이터 관리 방법; 및
일관된 보안 방법 중,
적어도 하나를 갖는,
아키텍처.
제 1 항에 있어서,
상기 세트 중의 뷰는 단일 분석 모듈에 의해서 사용되는,
아키텍처.
제 1 항에 있어서,
상기 세트 중의 뷰는 복수의 분석 모듈들에 의해서 사용되는,
아키텍처.
제 1 항에 있어서,
상기 복수의 분석 모듈들 중의 분석 모듈은 단일 애플리케이션에 의해서 사용되는,
아키텍처.
제 1 항에 있어서,
상기 복수의 분석 모듈들 중의 분석 모듈은 복수의 애플리케이션들에 의해서 사용되는,
아키텍처.
제 1 항에 있어서,
상기 세트 중의 각 뷰는 모듈 기반인 (modular),
아키텍처.
제 1 항에 있어서,
상기 복수의 분석 모듈 중의 각 분석 모듈은 모듈 기반인,
아키텍처.
플라즈마 프로세싱 관련 애플리케이션을 생성할 시에 공통 데이터 아키텍처 및 사용자 인터페이스를 제공하기 위한 컴퓨터 구현 방법으로서,
보안 요소, 데이터 관리 요소 및 사용자 인터페이스 (UI) 요소 중 적어도 하나를 포함하는 복수의 프레임워크 요소들을 셋업하는 단계;
뷰들의 세트를 생성하는 단계로서, 상기 뷰들의 세트는 상기 기반 층으로부터의 요소들을 사용하여서 개발되는, 상기 생성하는 단계;
적어도 하나의 분석 모듈을 생성하도록 하나 이상의 뷰들을 조합하는 단계; 및
적어도 하나의 애플리케이션을 생성하도록 하나 이상의 분석 모듈을 조합하는 단계를 포함하는,
컴퓨터 구현 방법.
제 12 항에 있어서,
상기 보안 요소를 포함하는 상기 복수의 프레임워크 요소들은 보안 규정 사항들을 확립함으로써 제공되는,
컴퓨터 구현 방법.
제 12 항에 있어서,
상기 데이터 관리 요소를 포함하는 상기 복수의 프레임워크 요소들은,
적어도 툴들의 세트로부터의 데이터 규정 사항들을 포함하는 데이터 타입을 확립하는 동작; 및
적어도 저장된 데이터의 위치, 저장된 데이터의 포맷 및 저장된 데이터를 액세스하기 위한 수단을 포함하는 데이터 관리 요소를 확립하는 동작 중,
적어도 하나에 의해서 제공되는,
컴퓨터 구현 방법.
제 12 항에 있어서,
상기 사용자 인터페이스 요소를 포함하는 상기 복수의 프레임워크 요소들은,
사용자 인터페이스 규정 사항 및 규칙 중 적어도 하나를 포함하는 그래픽 유저 인터페이스 (GUI) 요소를 확립하는 동작; 및
차트 및 테이블 (table) 중 적어도 하나를 포함하는 데이터 시각화 요소를 확립하는 동작 중,
적어도 하나에 의해서 제공되는,
컴퓨터 구현 방법.
제 12 항에 있어서,
상기 뷰들의 세트는 디스플레이 스크린 상의 페이지들의 세트로서 제공되며,
상기 뷰들의 세트 중의 각 뷰는,
일관된 네비게이션 모드를 갖는 일관된 사용자 인터페이스;
일관된 데이터 관리 방법; 및
일관된 보안 방법 중,
적어도 하나를 갖는,
컴퓨터 구현 방법.
제 12 항에 있어서,
상기 뷰들의 세트 중의 뷰는 단일 분석 모듈에 의해서 사용되는,
컴퓨터 구현 방법.
제 12 항에 있어서,
상기 뷰들의 세트 중의 뷰는 복수의 분석 모듈들에 의해서 사용되는,
컴퓨터 구현 방법.
제 12 항에 있어서,
상기 복수의 분석 모듈들 중의 분석 모듈은 단일 애플리케이션에 의해서 사용되는,
컴퓨터 구현 방법.
제 12 항에 있어서,
상기 복수의 분석 모듈들 중의 분석 모듈은 복수의 애플리케이션들에 의해서 사용되는,
컴퓨터 구현 방법.
제 12 항에 있어서,
상기 뷰들의 세트 중의 각 뷰는 모듈 기반인,
컴퓨터 구현 방법.
제 12 항에 있어서,
상기 복수의 분석 모듈 중의 각 분석 모듈은 모듈 기반인,
컴퓨터 구현 방법.