shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
적어도 2015년부터 ACE 아카이브는 이메일을 통해 피해자에게 악성 소프트웨어를 전달하는 데 사용되었다. 이 전략은 인기 있는 압축 소프트웨어가 ACE 아카이브를 압축 해제할 수 있지만, 메일 필터, 웹 콘텐츠 필터 및 바이러스 검사 소프트웨어와 같은 보안 제품에서 ACE 형식에 대한 지원이 일반적으로 미약했기 때문에 가능했다.
2019년 2월, WinRAR 및 기타 압축 제품에서 사용되는 unacev2.dll 라이브러리에서 여러 주요 보안 취약점이 발견되었다. WinACE 지원이 중단되었으므로 사용자들은 WinRAR 및 이 라이브러리를 사용하는 다른 제품에서 ACE 아카이브를 열지 않도록 권고된다. WinRAR은 버전 5.70부터 ACE 지원을 중단했으며, 유사한 제품들도 뒤를 따르고 있다.
Zstandard는 페이스북의 Yann Collet이 개발한 비손실 데이터 압축 알고리즘이다. Zstd는 해당 C로 된 참조 구현이며, 2016년 8월 31일 오픈 소스 소프트웨어로 공개되었다.
이 알고리즘은 2018년에 로 발행되었으며, 관련 미디어 타입 "application/zstd", 파일 확장자 "zst", 그리고 HTTP 콘텐츠 인코딩 "zstd"를 정의한다.
Zstandard는 DEFLATE 알고리즘(1991년에 개발되어 원본 ZIP 및 gzip 프로그램에 사용됨)과 유사한 압축비를 제공하지만, 특히 압축 해제 속도가 더 빠르도록 설계되었다. 압축 수준은 음수 7(가장 빠름)부터 22(압축 속도는 가장 느리지만 최상의 압축비)까지 조절 가능하다.
버전 1.3.2(2017년 10월)부터 zstd는 rzip 또는 lrzip과 유사하게 매우 긴 범위의 검색 및 중복 제거(, 128 MiB 창)를 선택적으로 구현한다.
압축 속도는 가장 빠른 수준과 가장 느린 수준 간에 20배 이상 차이가 날 수 있지만, 압축 해제는 균일하게 빠르며 가장 빠른 수준과 가장 느린 수준 간에 20% 미만의 차이를 보인다. Zstandard 명령줄에는 I/O 조건, 주로 출력 기록 속도에 따라 압축 수준을 변경하는 "적응형"() 모드가 있다.
Zstd는 최대 압축 수준에서 LZMA, LZHAM, PPMX와 유사한 압축비를 제공하며, Zstandard는 현재 파레토 최전선에 도달했으며, 유사하거나 더 나은 압축비를 가진 다른 어떤 현재 사용 가능한 알고리즘보다 빠르게 압축을 해제한다.
사전은 작은 파일의 압축비에 큰 영향을 미칠 수 있으므로 Zstandard는 사용자가 제공한 압축 사전을 사용할 수 있다. 또한 샘플 집합에서 사전을 생성할 수 있는 훈련 모드를 제공한다. 특히, 하나의 사전을 로드하여 파일 내에는 중복이 없더라도 파일 간에 중복이 있는 대규모 파일 집합(예: 로그 파일)을 처리할 수 있다.
Zstandard는 사전 일치 단계(LZ77)와 큰 검색 창, 그리고 빠른 엔트로피 부호화 단계를 결합한다. 이는 허프먼 부호화(리터럴 섹션의 항목에 사용됨)와 유한 상태 엔트로피(FSE) ANS의 빠른 테이블 버전인 tANS를 시퀀스 섹션의 항목에 사용한다. FSE가 기호 간에 상태를 전달하는 방식 때문에 압축 해제는 각 블록의 시퀀스 섹션 내 기호를 역순(마지막부터 처음까지)으로 처리하는 것을 포함한다.
리눅스 커널은 2017년 11월(버전 4.14)부터 btrfs 및 squashfs 파일 시스템의 압축 방법으로 Zstandard를 포함했다.
2017년 Allan Jude는 Zstandard를 FreeBSD 커널에 통합했으며, 이후 코어 덤프(사용자 프로그램 및 커널 패닉 모두)의 압축 옵션으로 통합되었다. 또한 개념 증명 OpenZFS 압축 방법을 만드는 데 사용되었으며 2020년에 통합되었다.
AWS 레드쉬프트 및 RocksDB 데이터베이스는 Zstandard를 사용한 필드 압축을 지원한다.
2018년 3월, 캐노니컬은 우분투 리눅스 배포판의 deb 패키지 압축 방법으로 zstd를 기본값으로 사용하는 것을 테스트했다. deb 패키지의 xz 압축과 비교할 때, zstd 레벨 19는 패키지 파일이 6% 더 커지는 대신 압축 해제 속도가 상당히 빠르다. 2018년 4월(버전 1.6~rc1)에 데비안(및 이후 우분투)에 지원이 추가되었다.
페도라는 2018년 5월(페도라 릴리스 28)에 RPM에 ZStandard 지원을 추가했으며, 2019년 10월(페도라 31) 릴리스 패키징에 사용했다. 페도라 33에서는 파일 시스템이 기본적으로 zstd로 압축된다.
아치 리눅스는 2019년 10월 pacman 5.2 패키지 관리자 출시와 함께 zstd를 패키지 압축 방법으로 지원했으며, 2020년 1월에는 공식 저장소의 패키지에 xz 대신 zstd로 전환했다. 아치는 codice_1를 사용하며, 모든 압축된 패키지의 총 크기는 0.8% 증가했지만(xz 대비), 압축 해제 속도는 14배 빨라졌고, 여러 스레드를 사용할 때 압축 해제 메모리는 50 MiB 증가했으며, 압축 메모리는 증가했지만 사용된 스레드 수에 비례한다. 아치 리눅스는 나중에 mkinitcpio 초기 램디스크 생성기의 기본 압축 알고리즘으로도 zstd로 전환했다.
압축 수준을 선택할 수 있는 알고리즘의 전체 구현은 닌텐도 스위치 하이브리드 게임 콘솔용 홈브루 커뮤니티에서 개발한 .NSZ/.XCZ 파일 형식에 사용된다. 또한 .RVZ Wii 및 닌텐도 게임큐브 디스크 이미지 파일 형식에서 지원되는 여러 압축 알고리즘 중 하나이다.
2020년 6월 15일, Zstandard는 zip 파일 형식의 버전 6.3.8에 코덱 번호 93으로 구현되었으며, 6월 1일에 출시된 버전 6.3.7에 구현된 이전 코덱 번호 20은 더 이상 사용되지 않게 되었다.
2024년 3월, 구글 크롬 버전 123(및 크로미엄 기반 브라우저인 브레이브 또는 마이크로소프트 엣지 등)은 HTTP 헤더 codice_2에 zstd 지원을 추가했다. 2024년 5월, 모질라 파이어폭스 릴리스 126.0은 HTTP 헤더 codice_2에 zstd 지원을 추가했다.
참조 구현은 BSD 허가서에 따라 깃허브에 게시되었다. 2016년 8월 31일 출시된 버전 1.0부터 추가적인 특허 권한 부여가 있었다.
2017년 8월 20일 출시된 버전 1.3.1부터 이 특허 부여는 철회되었고 라이선스는 BSD + GPLv2 이중 라이선스로 변경되었다.
렘펠-지브-오버휴머(Lempel–Ziv–Oberhumer, LZO)는 압축 해제 속도에 중점을 둔 비손실 데이터 압축 알고리즘이다.
1996년에 출시된 오리지널 "lzop" 구현은 마르쿠스 프란츠 크사버 요하네스 오버후머가 아브라함 렘펠과 야코브 지브의 이전 알고리즘을 기반으로 개발했다. LZO 라이브러리는 다음 특성을 가진 여러 알고리즘을 구현한다.
LZO는 중첩 압축 및 제자리 압축 해제를 지원한다. 블록 압축 알고리즘으로서 데이터 블록을 압축 및 압축 해제한다. 압축 및 압축 해제에 사용되는 블록 크기는 동일해야 한다. LZO는 데이터 블록을 일치(슬라이딩 딕셔너리) 및 일치하지 않는 리터럴 실행으로 압축하여 중복성이 높은 데이터에서 좋은 결과를 생성하고 압축 불가능한 데이터를 수용 가능하게 처리하며, 최소 1KB의 블록 크기로 측정할 때 원본 크기의 최대 1/64까지만 압축 불가능한 데이터를 확장한다.
참조 구현은 ANSI C로 작성되었으며 GNU 일반 공중 사용 허가서에 따라 자유 소프트웨어로 제공되었다. 코드의 저작권은 마르쿠스 F. X. J. 오버후머가 소유한다. 이 코드는 1996년에 처음 출판되었다. 오버후머는 또한 lzop이라는 명령줄 프런트엔드를 작성했다.
LZO 버전은 펄, 파이썬, 자바 언어에서 사용할 수 있다. 다양한 LZO 구현은 AIX, 아타리 TOS (아타리 ST), ConvexOS, IRIX, 리눅스, Mac OS, 닌텐도 64, 팜 OS, 플레이스테이션, 솔라리스, SunOS, VxWorks, Wii, Win32에서 작동하는 것으로 보고되었다.
FFmpeg의 libavutil 라이브러리는 비손실 비디오 압축을 위한 가능한 방법으로 자체 LZO 구현을 포함한다. FFmpeg의 압축 해제기 구현은 OpenConnect에서도 주니퍼 네트웍스 및 펄스 시큐어 VPN 서버에서 전송하는 LZO 압축 ESP 패킷을 지원하기 위해 사용된다.
리눅스 커널은 일부 기능에 LZO 구현을 사용한다:
LZO는 아래 뜻을 함의한다.
LZX는 LZ77 계열의 압축 알고리즘으로, DEFLATE의 약간 개선된 버전이다. 같은 이름의 파일 압축기의 이름이기도 하다. 둘 다 1990년대에 조너선 포브스와 토미 포우타넨이 발명했다.
LZX 알고리즘의 사용 사례.
아미가 LZX.
LZX는 저자들이 캐나다의 워털루 대학교에서 공부하던 중 1995년에 아미가 파일 압축기로 공개되었다. 이 소프트웨어는 당시 압축 소프트웨어에서 흔히 볼 수 있었던 셰어웨어였다. 등록된 버전에는 평가판에서 사용할 수 없었던 수정 사항과 개선 사항이 포함되어 있었다. 1997년, 저자들은 압축기에 대한 작업을 중단하고 등록을 받지 않게 되자, 누구나 등록된 버전을 사용할 수 있도록 무료 키 파일을 제공했다.
마이크로소프트 캐비닛 파일.
1996년 포브스는 마이크로소프트에 입사했고, 마이크로소프트의 캐비닛 압축기는 LZX 압축 방식을 포함하도록 향상되었다. 개선 사항에는 가변 검색 창 크기가 포함되었는데, 아미가 LZX는 64 KB로 고정되었고, 마이크로소프트 LZX는 32에서 2048 킬로바이트 (32,768에서 2,097,152바이트) 사이의 2의 거듭제곱으로 범위가 지정될 수 있었다. 인텔 80x86 "CALL" 명령을 감지하여 피연산자를 상대 주소 지정에서 절대 주소 지정으로 변환하는 특별한 전처리기가 추가되어, 동일한 위치에 대한 호출이 압축기가 일치시킬 수 있는 반복된 문자열을 생성하여 80x86 이진 코드의 압축률을 향상시켰다. (이 기술은 나중에 Branch-Call-Jump [BCJ] 필터링으로 일반화되었다.)
마이크로소프트 압축 HTML 도움말 (CHM) 파일.
마이크로소프트가 클래식 도움말 파일 형식을 대체하는 마이크로소프트 압축 HTML 도움말을 도입했을 때, 모든 HTML 데이터를 LZX 알고리즘으로 압축하도록 선택했다. 그러나 무작위 접근 속도를 향상시키기 위해, 압축기는 64킬로바이트(65,536바이트) 간격마다 재설정되고 32킬로바이트 간격마다 16비트 경계에 재정렬되도록 변경되었다. 따라서 HTMLHelp 소프트웨어는 항상 압축된 데이터 스트림의 시작부터 디코딩하는 대신 가장 가까운 64킬로바이트 간격을 즉시 탐색하고 거기서부터 디코딩을 시작할 수 있었다.
마이크로소프트 리더 (LIT) 파일.
마이크로소프트 리더용 마이크로소프트 LIT 파일은 단순히 CHM 파일 형식의 확장이며, 따라서 LZX 압축도 사용한다.
윈도우 이미징 포맷 (WIM) 파일.
윈도우 비스타와 윈도우 7의 설치/드라이브 이미지 파일 형식인 윈도우 이미징 포맷은 LZX를 압축 방식 중 하나로 사용한다.
CompactOS NTFS 파일 압축.
윈도우 10에서는 윈도우 이미징 포맷의 LZX 압축이 새로운 CompactOS NTFS 파일 압축에 사용된다.
엑스박스 라이브 아바타.
마이크로소프트는 디스크 및 대역폭 요구 사항을 줄이기 위해 엑스박스 라이브 아바타에 LZX 압축을 사용한다.
LZX 파일 압축 해제.
unlzx 프로그램과 XAD는 아미가 LZX 아카이브를 압축 해제할 수 있다. cabextract 프로그램은 LZX 방식을 사용하여 마이크로소프트 캐비닛 파일을 압축 해제할 수 있다. CHM 문서에 명시된 바와 같이, CHM 파일을 역컴파일하거나 보는 데 사용할 수 있는 다양한 크로스 플랫폼 도구들이 있다. LIT 파일은 Convert LIT 소프트웨어를 사용하여 압축 해제할 수 있다.
Industry Foundation Classes(IFC)는 건축, 빌딩, 건설 산업 데이터(ABCII)를 설명하기 위한 CAD 데이터 교환 데이터 스키마이다. IFC 파일 형식은 ISO 10303-21 표준을 기반으로 하며 ABCII의 정의는 기본 EXPRESS를 사용하여 문서화된다.
이것은 단일 공급업체나 공급업체 그룹이 통제하지 않는 플랫폼 독립적인 공개 데이터 스키마 사양이다. buildingSMART(이전의 국제 상호운용성 연합, IAI)가 건축, 공학 및 건설(AEC) 산업에서의 상호운용성을 촉진하기 위해 개발한 데이터 모델을 가진 객체 기반 데이터 스키마이며, 빌딩 정보 모델링(BIM) 기반 프로젝트에서 일반적으로 사용되는 협업 형식이다. IFC 모델 사양은 공개되어 있으며 이용 가능하다. ISO에 등록되어 있으며 공식 국제 표준 ISO 16739-1:2024이다.
상호운용성에 중점을 둔 덕분에 2010년 덴마크 정부는 공공 지원 건축 프로젝트에 IFC 형식의 사용을 의무화했다. 2017년 핀란드 국영 시설 관리 회사 Senate Properties는 모든 프로젝트에서 IFC 호환 소프트웨어와 BIM 사용을 요구하기 시작했다. 또한 노르웨이 정부, 보건 및 국방 클라이언트 조직은 모든 프로젝트에서 IFC BIM 사용을 요구하며, 많은 지자체, 개인 클라이언트, 계약자 및 설계자들도 IFC BIM을 사업에 통합했다. 건설 분야에서 IFC 데이터 스키마의 인기는 주로 형상 교환 목적으로 계속 증가했다.
IFC 이니셔티브는 1994년 오토데스크가 통합 애플리케이션 개발을 지원할 C++ 클래스 세트 개발에 대한 자문을 위해 업계 컨소시엄을 구성하면서 시작되었다. 12개의 미국 회사가 이 컨소시엄에 참여했다. 이 회사들에는 AT&amp;T, HOK 건축가, 하니웰, 캐리어, 티쉬만 및 버틀러 매뉴팩처링이 포함되었다. 처음에는 상호운용성 산업 연합으로 명명되었던 이 연합은 1995년 9월에 모든 이해관계자에게 회원 자격을 개방하고 1997년에 국제 상호운용성 연합으로 이름을 변경했다. 새로운 연합은 AEC 빌딩 수명 주기에 대응하는 중립적인 AEC 제품 모델로서 Industry Foundation Class(IFC)를 출판하는 것을 목표로 비영리 산업 주도 조직으로 재편성되었다. 2005년에 추가적인 이름 변경이 있었으며, IFC 사양은 현재 buildingSMART에 의해 개발 및 유지 관리되고 있다.
IFC 사양.
다음 IFC 사양 버전이 사용 가능하다
IFC는 동일한 기본 데이터를 다양한 인코딩으로 지원하는 여러 파일 형식을 정의한다.
IFC-SPF는 ASCII 형식으로, 사람이 읽을 수 있지만 파일 크기 팽창, 파일을 처음부터 끝까지 순차적으로 읽어야 함, 파일 중간 추출 불가능, 파일 구문 분석 속도 느림, 정의가 비계층적이라는 일반적인 ASCII 파일 문제점을 겪는다. ifcXML 및 ifcZIP 외에도 최신 데이터 형식에는 RDF/XML 또는 터틀(ifcOWL 온톨로지 사용), ifcJSON (자바스크립트 객체 표기법, 널리 사용 가능) 및 ifcHDF5 (계층적 데이터 형식 v5, 바이너리)가 포함된다. 2020년에 buildingSmart는 두 가지 JSON 프로젝트를 진행 중이었다: ifcJSON v4(EXPRESS 기반 IFC v4의 직접 매핑)와 ifcJSON v5, 그리고 IFC를 바이너리 형식으로 전환하는 연구 프로젝트.
IFC는 EXPRESS 기반의 엔티티-관계 모델을 정의하며, 객체 기반 상속 계층 구조로 구성된 수백 개의 엔티티를 포함한다. 엔티티의 예로는 IfcWall과 같은 빌딩 요소, IfcExtrudedAreaSolid와 같은 형상, IfcCartesianPoint와 같은 기본 구조가 있다.
가장 추상적인 수준에서 IFC는 모든 엔티티를 루트 엔티티와 비루트 엔티티로 나눈다. 루트 엔티티는 IfcRoot에서 파생되며, 이름, 설명 및 개정 제어 속성과 함께 ID(GUID) 개념을 갖는다. 비루트 엔티티는 ID를 갖지 않으며, 인스턴스는 루트 인스턴스에서 직접 또는 간접적으로 참조될 때만 존재한다. IfcRoot는 세 가지 추상 개념으로 세분된다: 객체 정의, 관계 및 속성 집합:
IfcObjectDefinition은 객체 발생과 객체 유형으로 나뉜다. IfcObject는 일련 번호와 물리적 배치를 갖는 제품 설치와 같은 객체 발생을 캡처한다. IfcTypeObject는 특정 모델 번호와 공통 모양을 갖는 제품 유형과 같은 유형 정의(또는 템플릿)를 캡처한다. 발생 및 유형은 배우("누가"), 제어("왜"), 그룹("무엇을"), 제품("어디에"), 프로세스("언제"), 자원("어떻게")의 여섯 가지 기본 개념으로 더 세분된다.
IfcRelationship은 객체 간의 관계를 캡처한다. 기본 관계 유형은 구성, 할당, 연결, 연관 및 정의의 다섯 가지이다.
IfcPropertyDefinition은 동적으로 확장 가능한 속성 집합을 캡처한다. 속성 집합은 하나 이상의 속성을 포함하며, 이는 단일 값(예: 문자열, 숫자, 단위 측정), 제한된 값(최소값 및 최대값 포함), 열거형, 값 목록, 값 테이블 또는 데이터 구조일 수 있다. IFC는 특정 유형에 대해 수백 개의 속성 집합을 정의하지만, 사용자 정의 속성 집합은 애플리케이션 공급업체 또는 최종 사용자가 정의할 수 있다.
IfcProduct는 모든 물리적 객체의 기본 클래스이며 공간 요소, 물리적 요소, 구조 분석 항목 및 기타 개념으로 세분된다. 제품은 관련 재료, 형상 표현 및 공간 내 배치를 가질 수 있다. 공간 요소에는 IfcSite, IfcBuilding, IfcBuildingStorey 및 IfcSpace가 포함된다. 물리적 빌딩 요소에는 IfcWall, IfcBeam, IfcDoor, IfcWindow, IfcStair 등이 포함된다. 분배 요소(HVAC, 전기, 배관)는 요소가 다양한 서비스에 대한 특정 연결을 가질 수 있는 포트 개념을 가지며, 시스템을 형성하기 위해 케이블, 파이프 또는 덕트를 사용하여 연결된다. 벽에 문이나 창문으로 채워지는 개구부가 있는 것과 같은 빌딩 요소에는 다양한 연결 관계가 사용된다.
재료는 제품 전체에 대해 정의될 수도 있고, 지정된 부분에 대한 층, 프로필 또는 구성 요소로 정의될 수도 있다.
표현은 명시적 3D 형상에 대해 정의될 수 있으며, 선택적으로 매개변수 제약 조건으로 정의될 수 있다. 각 표현은 잘 알려진 이름을 가진 IfcShapeRepresentation으로 식별된다.
배치는 위치, 수직 각도 및 수평 각도를 나타낼 수 있다.
수량은 총 면적, 총 부피, 총 중량, 순 중량 등과 같은 산출 목적으로 정의될 수 있다. IFC는 각 요소 유형에 특정한 다양한 수량과 형상 및 관계에 따른 계산 방법을 정의한다.
IfcProcess는 프로세스의 기본 클래스이며 작업, 이벤트 및 절차로 세분된다. 프로세스는 기간을 가질 수 있으며 특정 시간 기간에 발생하도록 예약될 수 있다. 프로세스는 선행 작업이 완료된 후 후속 작업이 시작되도록 주요 경로법에 따라 순서가 지정될 수 있다. 프로세스는 요약 집계를 위해 하위 프로세스로 중첩될 수 있다. 프로세스는 수행된 작업으로 생성된 출력을 나타내는 제품에 할당될 수 있다.
IfcResource는 자원의 기본 클래스이며 재료, 노동, 장비, 하청 계약, 인력 등으로 세분된다. 자원은 다양한 비용과 가용성 일정을 가질 수 있다. 자원은 세분화된 할당을 위해 하위 자원으로 중첩될 수 있다. 자원은 자원을 대신하여 수행되는 작업을 나타내는 프로세스에 할당될 수 있다.
IfcProject는 전체 프로젝트를 캡슐화하고 프로젝트 이름, 설명, 기본 단위, 통화, 좌표계 및 기타 컨텍스트 정보를 나타낸다. 유효한 IFC 파일은 항상 정확히 하나의 IfcProject 인스턴스를 포함해야 하며, 모든 다른 객체는 직간접적으로 이와 관련된다. 프로젝트는 특정 용도에 따라 여러 건물, 여러 참여자 및 여러 단계를 포함할 수 있다.
프로젝트별 정보 외에도 IfcProject는 제품 유형과 같이 공유 정의를 가져올 수 있는 외부 프로젝트를 참조할 수도 있다. 각 외부 프로젝트는 IfcProjectLibrary [IFC2x4]와 IfcRelAssociatesLibrary 및 IfcLibraryInformation을 사용하여 가져온 프로젝트 라이브러리의 특정 개정을 식별한다.
프로젝트는 개정 관리를 지원하며, 모든 IfcRoot 기반 엔티티는 고유 식별자를 가지며 추가, 수정, 삭제 또는 변경 없음으로 표시될 수 있다. 이러한 기능은 여러 IFC 파일을 결정적으로 병합할 수 있게 하여 사람의 개입 없이 데이터 무결성을 보장한다.
자동 시험 장비(automatic test equipment) 또는 자동화 시험 장비(automated test equipment, ATE)는 자동화를 사용하여 측정값을 신속하게 수행하고 시험 결과를 평가하여 피시험 장치 (DUT), 시험 장비 (EUT) 또는 시험 장치 (UUT)로 알려진 장치에 대한 시험을 수행하는 모든 장치를 말한다. ATE는 간단한 컴퓨터 제어 디지털 멀티미터일 수도 있고, 정교한 전자 패키지 부품이나 웨이퍼 테스트 (시스템 온 칩 및 집적 회로 포함)의 결함을 자동으로 테스트하고 진단할 수 있는 수십 개의 복잡한 테스트 장비(실제 또는 시뮬레이션된 전자 테스트 장비)를 포함하는 복잡한 시스템일 수도 있다.
ATE는 전자 제조 산업에서 제조된 전자 부품 및 시스템을 테스트하는 데 널리 사용된다. ATE는 항공전자 및 자동차의 전자 모듈을 테스트하는 데도 사용된다. 레이더 및 무선 통신과 같은 군사 애플리케이션에 사용된다.
반도체 산업에서.
반도체 소자 테스트용으로 명명된 반도체 ATE는 간단한 부품(저항기, 축전기, 유도자)부터 집적 회로(IC), 인쇄 회로 기판(PCB), 복잡하고 완전히 조립된 전자 시스템에 이르기까지 광범위한 전자 장치 및 시스템을 테스트할 수 있다. 이를 위해 프로브 카드가 사용된다. ATE 시스템은 특정 장치가 작동하는지 확인하거나 최종 소비자 제품에 사용되기 전에 결함을 신속하게 찾아내는 데 필요한 테스트 시간을 줄이도록 설계되었다. 제조 비용을 절감하고 수율을 향상시키기 위해 반도체 장치는 제조 후 테스트를 거쳐 불량 장치가 소비자에게 전달되는 것을 방지해야 한다.
반도체 ATE 아키텍처는 하나 이상의 소스 및 캡처 장비(아래에 나열)를 동기화하는 마스터 컨트롤러(컴퓨터로 구성된다. 역사적으로 ATE 시스템은 맞춤형 컨트롤러 또는 전자계전기를 사용했다. 피시험 장치(DUT)는 핸들러 또는 프로버라고 하는 다른 로봇 기계를 통해 ATE에 물리적으로 연결되며, ATE의 리소스를 DUT에 맞추는 맞춤형 인터페이스 테스트 어댑터(ITA) 또는 "픽스처"를 통해 연결된다.
산업용 PC.
산업용 PC는 신호 발생기/감지 카드를 수용하기 위한 충분한 PCI/PCIe 슬롯을 갖춘 19인치 랙 표준으로 패키징된 일반 데스크톱 컴퓨터이다. 이는 ATE에서 컨트롤러 역할을 한다. 테스트 애플리케이션 개발 및 결과 저장은 이 PC에서 관리된다. 대부분의 최신 반도체 ATE에는 광범위한 매개변수를 생성하거나 측정하는 여러 컴퓨터 제어 장비가 포함되어 있다. 이 장비에는 장치 전원 공급 장치(DPS), 매개변수 측정 장치(PMU), 임의 파형 발생기(AWG), 디지털 변환기, 디지털 IO 및 유틸리티 공급 장치가 포함될 수 있다. 이 장비는 DUT에 대한 다양한 측정값을 수행하며, 장비는 적절한 시간에 파형을 생성하고 측정하도록 동기화된다. 응답 시간 요구 사항에 따라 실시간 시스템도 자극 및 신호 캡처용으로 고려된다.
대량 인터커넥트.
대량 인터커넥트는 테스트 장비(PXI, VXI, LXI, GPIB, SCXI, &amp; PCI)와 테스트 중인 장치/단위(D/UUT) 간의 커넥터 인터페이스이다. 이 섹션은 ATE와 D/UUT 간에 신호가 들어오고 나가는 노드 역할을 한다.
예: 간단한 전압 측정.
예를 들어, 특정 반도체 장치의 전압을 측정하기 위해 ATE의 디지털 신호 처리(DSP) 장비는 전압을 직접 측정하고 결과를 컴퓨터로 보내 신호 처리하여 원하는 값이 계산된다. 이 예는 전류계와 같은 기존 장비가 장비가 수행할 수 있는 측정 횟수와 측정에 걸리는 시간의 제한으로 인해 많은 ATE에서 사용되지 않을 수 있음을 보여준다. 매개변수를 측정하기 위해 DSP를 사용하는 한 가지 주요 장점은 시간이다. 전기 신호의 최대 전압과 신호의 다른 매개변수를 계산해야 하는 경우, 피크 검출기 장비뿐만 아니라 다른 매개변수를 테스트하기 위한 다른 장비도 사용해야 한다. 그러나 DSP 기반 장비를 사용하는 경우 신호의 샘플을 만들고 단일 측정에서 다른 매개변수를 계산할 수 있다.
테스트 매개변수 요구사항 vs. 테스트 시간.
모든 장치가 동일하게 테스트되는 것은 아니다. 테스트는 비용을 추가하므로 저가형 부품은 거의 완전히 테스트되지 않는 반면, 의료 또는 고가 부품(신뢰성이 중요함)은 자주 테스트된다.
그러나 장치의 기능과 최종 사용자에 따라 모든 매개변수를 테스트할 필요가 있을 수도 있고 없을 수도 있다. 예를 들어, 장치가 의료 또는 인명 구조 제품에 적용되는 경우 많은 매개변수를 테스트해야 하며 일부 매개변수는 보장되어야 한다. 그러나 테스트할 매개변수를 결정하는 것은 비용 대비 수율을 기반으로 하는 복잡한 결정이다. 장치가 수천 개의 게이트가 있는 복잡한 디지털 장치인 경우 테스트 결함 범위가 계산되어야 한다. 여기서도 장치의 주파수, I/O 수 및 유형, 최종 사용 애플리케이션을 기반으로 하는 테스트 경제성에 따라 결정이 복잡해진다.
핸들러 또는 프로버 및 장치 테스트 어댑터.
ATE는 패키징된 부품(일반적인 IC '칩') 또는 실리콘 웨이퍼에 직접 사용될 수 있다. 패키징된 부품은 핸들러를 사용하여 장치를 맞춤형 인터페이스 보드에 배치하는 반면, 실리콘 웨이퍼는 고정밀 프로브로 직접 테스트된다. ATE 시스템은 핸들러 또는 프로버와 상호 작용하여 DUT를 테스트한다.
핸들러가 있는 패키징된 부품 ATE.
ATE 시스템은 일반적으로 "핸들러"라고 불리는 자동 배치 도구와 인터페이스하여 피시험 장치(DUT)를 인터페이스 테스트 어댑터(ITA)에 물리적으로 배치하여 장비로 측정할 수 있도록 한다. 인터페이스 테스트 어댑터(ITA)는 ATE와 피시험 장치(UUT라고도 함) 사이에 전자 연결을 제공하는 장치이지만, ATE와 DUT 사이에 신호를 조정하기 위한 추가 회로를 포함할 수도 있고 DUT를 장착하기 위한 물리적 시설을 가질 수도 있다. 마지막으로, 소켓은 ITA와 DUT 사이의 연결을 연결하는 데 사용된다. 소켓은 생산 현장의 엄격한 요구 사항을 견뎌야 하므로 일반적으로 자주 교체된다.
간단한 전기 인터페이스 다이어그램: ATE → ITA → DUT (패키지) ← 핸들러
프로버가 있는 실리콘 웨이퍼 ATE.
웨이퍼 기반 ATE는 일반적으로 실리콘 웨이퍼를 가로질러 장치를 테스트하는 프로버라는 장치를 사용한다.
간단한 전기 인터페이스 다이어그램: ATE → 프로버 → 웨이퍼 (DUT)
멀티사이트.
테스트 시간을 개선하는 한 가지 방법은 여러 장치를 동시에 테스트하는 것이다. ATE 시스템은 이제 ATE 리소스가 각 사이트에서 공유되는 여러 "사이트"를 지원할 수 있다. 일부 리소스는 병렬로 사용할 수 있고, 다른 리소스는 각 DUT에 직렬화되어야 한다.
ATE 프로그래밍.
ATE 컴퓨터는 표준 및 독점 응용 프로그래밍 인터페이스(API)를 통해 ATE 장비를 제어하기 위한 추가 명령문을 사용하여 최신 컴퓨터 언어(C, C++, 자바, VEE, 파이썬, LabVIEW 또는 스몰토크)를 사용한다. 또한 Abbreviated Test Language for All Systems (ATLAS)와 같은 일부 전용 컴퓨터 언어도 존재한다. 자동 테스트 장비는 NI의 TestStand와 같은 테스트 실행 엔진을 사용하여 자동화될 수도 있다.
때때로 자동 시험 패턴 생성이 일련의 테스트를 설계하는 데 도움이 되도록 사용된다.
테스트 데이터 (STDF).
반도체 산업에서 사용되는 많은 ATE 플랫폼은 표준 테스트 데이터 형식(STDF)을 사용하여 데이터를 출력한다.
자동 시험 장비 진단은 ATE 시험의 일부로, 고장난 구성 요소를 판별한다. ATE 시험은 두 가지 기본 기능을 수행한다. 첫째는 피시험 장치가 올바르게 작동하는지 여부를 시험하는 것이다. 둘째는 피시험 장치가 올바르게 작동하지 않을 때 그 이유를 진단하는 것이다. 진단 부분은 시험에서 가장 어렵고 비용이 많이 드는 부분일 수 있다. ATE는 고장을 구성 요소의 클러스터 또는 모호성 그룹으로 축소하는 것이 일반적이다. 이러한 모호성 그룹을 줄이는 한 가지 방법은 ATE 시스템에 아날로그 시그니처 분석 테스트를 추가하는 것이다. 진단은 종종 플라잉 프로브 테스트의 도움을 받는다.
테스트 시스템 구성에 고속 스위칭 시스템을 추가하면 여러 장치를 더 빠르고 비용 효율적으로 테스트할 수 있으며, 테스트 오류와 비용을 모두 줄이도록 설계되었다. 테스트 시스템의 스위칭 구성을 설계하려면 전환할 신호와 수행할 테스트, 그리고 사용 가능한 스위칭 하드웨어 폼 팩터에 대한 이해가 필요하다.
테스트 장비 플랫폼.
여러 모듈형 전자 계측 플랫폼이 현재 자동화된 전자 테스트 및 측정 시스템을 구성하는 데 널리 사용되고 있다. 이러한 시스템은 전자 장치 및 서브어셈블리의 입고 검사, 품질 보증 및 생산 테스트에 널리 사용된다. 산업 표준 통신 인터페이스는 외부 PC에서 실행되는 맞춤형 소프트웨어 애플리케이션의 제어 하에 "랙 앤 스택" 또는 섀시/메인프레임 기반 시스템에서 신호 소스와 측정 장비를 연결한다.
범용 인터페이스 버스(GPIB)는 센서 및 프로그래밍 가능한 장비를 컴퓨터에 연결하는 데 사용되는 IEEE-488(전기전자공학자협회에서 만든 표준) 표준 병렬 인터페이스이다. GPIB는 8MB/s 이상의 데이터 전송이 가능한 디지털 8비트 병렬 통신 인터페이스이다. 24핀 커넥터를 사용하여 최대 14개의 장비를 시스템 컨트롤러에 데이지 체인 방식으로 연결할 수 있다. 이 인터페이스는 장비에 존재하는 가장 일반적인 I/O 인터페이스 중 하나이며 특히 장비 제어 애플리케이션을 위해 설계되었다. IEEE-488 사양은 이 버스를 표준화하고 전기적, 기계적, 기능적 사양을 정의하는 동시에 기본 소프트웨어 통신 규칙도 정의했다. GPIB는 장비 제어를 위한 견고한 연결이 필요한 산업 환경의 애플리케이션에 가장 적합하다.
원래 GPIB 표준은 1960년대 후반 휴렛 팩커드에서 제조하는 프로그래밍 가능한 장비를 연결하고 제어하기 위해 개발되었다. 디지털 컨트롤러와 프로그래밍 가능한 테스트 장비의 도입으로 다양한 공급업체의 장비와 컨트롤러 간의 통신을 위한 표준 고속 인터페이스가 필요해졌다. 1975년 IEEE는 인터페이싱 시스템의 전기적, 기계적, 기능적 사양을 포함하는 ANSI/IEEE 표준 488-1975, 즉 프로그래밍 가능한 장비용 IEEE 표준 디지털 인터페이스를 발행했다. 이 표준은 1978년(IEEE-488.1)과 1990년(IEEE-488.2)에 개정되었다. IEEE 488.2 사양에는 프로그래밍 가능한 장비용 표준 명령(SCPI)이 포함되어 있으며, 각 장비 클래스가 준수해야 하는 특정 명령을 정의한다. SCPI는 이러한 장비 간의 호환성과 구성 가능성을 보장한다.
IEEE-488 버스는 사용하기 쉽고 다양한 프로그래밍 가능한 장비 및 자극을 활용할 수 있기 때문에 오랫동안 인기를 누렸다. 그러나 대규모 시스템에는 다음과 같은 제한이 있다.
계측용 LAN 확장 (LXI).
LXI 표준은 이더넷을 사용하는 계측 및 데이터 획득 시스템을 위한 통신 프로토콜을 정의한다. 이러한 시스템은 저비용의 개방형 표준 LAN(이더넷)을 사용하는 소형 모듈형 장비를 기반으로 한다. LXI 준수 장비는 카드 케이지 아키텍처의 비용 및 폼 팩터 제약 없이 모듈형 장비의 크기 및 통합 이점을 제공한다. 이더넷 통신을 통해 LXI 표준은 상업, 산업, 항공 우주 및 군사 애플리케이션의 광범위한 분야에서 유연한 패키징, 고속 I/O 및 LAN 연결의 표준화된 사용을 가능하게 한다. 모든 LXI 준수 장비에는 비LXI 장비와의 통신을 단순화하기 위한 IVI(Interchangeable Virtual Instrument) 드라이버가 포함되어 있으므로 LXI 준수 장치는 자체적으로 LXI 준수가 아닌 장비(예: GPIB, VXI, PXI 등을 사용하는 장비)와 통신할 수 있다. 이는 장비의 하이브리드 구성을 구축하고 작동하는 것을 단순화한다.
LXI 장비는 때때로 임베디드 테스트 스크립트 프로세서를 사용하여 테스트 및 측정 애플리케이션을 구성하기 위한 스크립팅을 사용한다. 스크립트 기반 장비는 많은 애플리케이션에 대해 아키텍처 유연성, 향상된 성능 및 낮은 비용을 제공한다. 스크립팅은 LXI 장비의 이점을 향상시키며, LXI는 스크립팅을 가능하게 하고 향상시키는 기능을 제공한다. 계측용 현재 LXI 표준은 장비가 프로그래밍 가능하거나 스크립팅을 구현해야 한다고 요구하지 않지만, LXI 사양의 여러 기능은 프로그래밍 가능한 장비를 예상하고 LXI 준수 장비에서 스크립팅 기능을 향상시키는 유용한 기능을 제공한다.
계측용 VME 확장 (VXI).
VXI 버스 아키텍처는 VME버스를 기반으로 하는 자동화 테스트를 위한 개방형 표준 플랫폼이다. 1987년에 도입된 VXI는 모든 유로카드 폼 팩터를 사용하며 트리거 라인, 로컬 버스 및 측정 애플리케이션에 적합한 기타 기능을 추가한다. VXI 시스템은 다양한 VXI 계측 모듈을 설치할 수 있는 최대 13개의 슬롯이 있는 메인프레임 또는 섀시를 기반으로 한다. 섀시는 또한 섀시 및 포함된 계측기에 필요한 모든 전원 공급 장치 및 냉각 요구 사항을 제공한다. VXI 버스 모듈은 일반적으로 6U 높이이다.
계측용 PCI 확장 (PXI).
PXI는 데이터 수집 및 실시간 제어 시스템에 특화된 주변 버스이다. 1997년에 도입된 PXI는 CompactPCI 3U 및 6U 폼 팩터를 사용하며 트리거 라인, 로컬 버스 및 측정 애플리케이션에 적합한 기타 기능을 추가한다. PXI 하드웨어 및 소프트웨어 사양은 PXI 시스템즈 얼라이언스에서 개발 및 유지 관리한다. 전 세계 50개 이상의 제조업체가 PXI 하드웨어를 생산한다.
범용 직렬 버스 (USB).
USB는 키보드 및 마우스와 같은 주변 장치를 PC에 연결한다. USB는 단일 포트에 최대 127개의 장치를 처리할 수 있는 플러그 앤 플레이 버스이며, 이론상 최대 처리량은 480 Mbit/s(USB 2.0 사양으로 정의된 고속 USB)이다. USB 포트는 PC의 표준 기능이므로 기존 직렬 포트 기술의 자연스러운 진화이다. 그러나 USB 케이블은 산업용 등급이 아니며, 노이즈에 민감하고, 우발적으로 분리될 수 있으며, 컨트롤러와 장치 사이의 최대 거리는 30m이므로 여러 가지 이유로 산업용 테스트 및 측정 시스템 구축에 널리 사용되지 않는다. RS-232와 마찬가지로 USB는 견고한 버스 연결이 필요하지 않은 실험실 환경의 애플리케이션에 유용하다.
RS-232.
RS-232는 분석 및 과학 기기뿐만 아니라 프린터와 같은 주변 장치 제어에도 널리 사용되는 직렬 통신 사양이다. GPIB와 달리 RS-232 인터페이스로는 한 번에 하나의 장치만 연결하고 제어할 수 있다. RS-232는 또한 일반적으로 20KB/s 미만의 데이터 전송률을 가진 비교적 느린 인터페이스이다. RS-232는 더 느리고 견고하지 않은 연결과 호환되는 실험실 애플리케이션에 가장 적합하다. ±24볼트 전원으로 작동한다.
경계 스캔.
경계 스캔은 IC의 핀을 제어하고 테스트 대상(UUT)에 대한 연속성(상호 연결) 테스트와 논리 장치 또는 장치 그룹에 대한 기능 클러스터 테스트를 용이하게 하기 위해 PCB 수준 또는 시스템 수준 인터페이스 버스로 구현될 수 있다. 또한 IC 자체에 내장될 수 있는 다른 계측(IEEE 1687 참조) 또는 외부 제어 가능한 테스트 시스템의 일부인 계측을 위한 제어 인터페이스로도 사용될 수 있다.
가장 최근에 개발된 테스트 시스템 플랫폼 중 하나는 온보드 테스트 스크립트 프로세서와 고속 버스를 갖춘 계측기를 사용한다. 이 접근 방식에서 하나의 "마스터" 계측기는 고속 LAN 기반 트리거 동기화 및 장치 간 통신 버스를 통해 연결된 테스트 시스템의 다양한 "슬레이브" 계측기 작동을 제어하는 테스트 스크립트(작은 프로그램)를 실행한다. 스크립팅은 스크립트 언어로 프로그램을 작성하여 일련의 동작을 조정하는 것이다.
이 접근 방식은 테스트 및 측정 애플리케이션의 특징인 작은 메시지 전송에 최적화되어 있다. 네트워크 오버헤드가 거의 없고 100Mbit/초 데이터 전송률을 제공하여 실제 애플리케이션에서 GPIB 및 100BaseT 이더넷보다 훨씬 빠르다.
이 플랫폼의 장점은 연결된 모든 장비가 하나의 밀접하게 통합된 다중 채널 시스템처럼 작동하여 사용자가 필요한 채널 수를 비용 효율적으로 맞추기 위해 테스트 시스템을 확장할 수 있다는 점이다. 이러한 유형의 플랫폼에 구성된 시스템은 마스터 장치가 소싱, 측정, 합격/불합격 결정, 테스트 시퀀스 흐름 제어, 분류 및 구성 요소 핸들러 또는 프로버를 제어하는 완전한 측정 및 자동화 솔루션으로 독립적으로 작동할 수 있다. 전용 트리거 라인 지원은 이 고속 버스로 연결된 온보드 테스트 스크립트 프로세서를 갖춘 여러 장비 간의 동기화된 작업을 추가 트리거 연결 없이 달성할 수 있음을 의미한다.
패러독스(Paradox)는 현재 코렐 코퍼레이션에서 발행하는 관계형 데이터베이스 관리 시스템이다.
이 소프트웨어는 원래 Ansa 소프트웨어에서 MS-DOS용으로 출시되었고, 그 회사를 인수한 볼랜드에서 업데이트했다. 1991년 중반, 볼랜드는 애슈턴-테이트와 경쟁 DBASE 제품군을 인수하는 절차를 시작했다. 윈도우 버전은 1992년 볼랜드에서 출시될 예정이었으나, 마이크로소프트의 윈도우용 액세스가 출시될 때까지인 1993년 1월로 연기되었다. 마지막 업데이트는 2009년이었다.
DOS용 패러독스.
DOS용 패러독스는 리처드 슈워츠와 로버트 쇼스탁이 처음 작성하여 1985년 그들의 벨몬트 캘리포니아 기반 회사 Ansa 소프트웨어에서 출시한 관계형 데이터베이스 관리 시스템이다.
뉴욕 타임스는 이 소프트웨어를 "인공지능 기술을 광범위하게 사용하는 떠오르는 소프트웨어 세대 중 하나"로 묘사했으며, 패러독스가 경쟁사인 애슈턴 테이트의 DBASE 파일을 읽을 수 있다는 점을 언급했다.
1987년 9월, 볼랜드는 Paradox/DOS 2.0 소프트웨어를 포함한 Ansa 소프트웨어를 인수했다. 주목할 만한 고전 버전은 3.5와 4.5였다. 3.5 버전까지는 1.0의 진화형이었다. 4.0 및 4.5 버전은 볼랜드 C++ 윈도잉 툴킷으로 재정비되었고 다른 연속 확장 메모리 접근 방식을 사용했다.
Paradox/DOS는 1980년대 후반과 1990년대 초반에 성공적인 DOS 기반 데이터베이스였다. 그 당시에는 DBASE와 그 xBase 클론 (폭스프로, 클리퍼)이 시장을 지배했다. 다른 주목할 만한 경쟁자로는 클라리온, DataEase, , DataFlex가 있었다.
Paradox/DOS를 구별하는 특징은 다음과 같다.
MS-DOS 에뮬레이터로는 dbDOS (유료 제품)와 https://www.vdos.info/ (프리웨어 옵션 제공)가 있으며, 둘 다 Windows Vista 이상 64비트 운영 체제에서 DOS용 Paradox 애플리케이션 (예: DOS용 Paradox 4.5)을 실행할 수 있는 기능을 제공한다.
윈도우용 패러독스.
윈도우용 패러독스는 DOS용 패러독스와 명확히 다르며, 다른 프로그래머 팀에 의해 제작되었다. 윈도우용 패러독스 애플리케이션은 ObjectPAL이라는 다른 프로그래밍 언어로 프로그래밍된다. DOS 제품의 핵심 기능인 QBE와 데이터베이스 엔진은 DOS 코드를 유지한 포트였지만, PAL에서 ObjectPAL로의 호환성이 크게 깨졌고, 양식 및 보고서의 GUI 디자인 메타포로 전환되었다. ObjectPAL 변경은 논란이 많았지만, PAL이 윈도우에는 해당되지 않는 키 입력 기록 동작을 기반으로 했기 때문에 강제되었다. 키 입력 기록 대신 하이퍼카드의 아이디어를 기반으로 한 객체 기반 언어가 사용되었다. 양식 및 보고서 디자이너는 상세한 레이아웃을 위해 확대/축소 모드에서 작업할 수 있는 기능을 포함하여 장치 독립적인 크기 조절을 사용했다. 마우스 오른쪽 클릭은 제록스 알토와 스몰토크에서 영감을 받아 현재 거의 모든 윈도우 프로그램에서 보편적으로 사용되는 방식으로 양식 및 보고서 속성에 접근하는 데 사용되었다. ObjectPAL은 (하이퍼카드처럼) 시각적 객체와 관련되어 있었으며, 오른쪽 클릭으로도 드러났다. 속성 검사 및 레이아웃 도구는 NeXT에서 빌려온 아이디어로 "고정"되어 화면에 유지될 수 있었으며, 현재 윈도우에서 꽤 널리 채택되었다.
개발 초기 약 1년 동안 객체 지향 코드는 매크로의 도움을 받아 C로 작성되었고, 터보 C++가 출시되면서 나머지 코드 부분은 C++로 작성되었다. 버전 1.0 출시 전까지 제품 관리자는 조 던컨이었다. 개발 및 QA 팀은 총 약 30명이었다.
윈도우용 패러독스와 밀접하게 관련된 프로젝트인 윈도우용 쿼트로 프로는 모두 1990년 봄, 윈도우 3.0의 베타 버전에서 개발을 시작했다. 윈도우용 패러독스는 원래 계획보다 약 1년 지연되어 1993년 초에 출시되었다. 그 이유는 많았지만, 본질적으로 첫 번째 버전 운영 체제에서 새로운 도구를 사용하여 GUI 패러다임으로 전환하는 대규모 재작성에 객체 지향 언어를 사용하는 것은 전혀 놀라운 일이 아니었다. 그럼에도 불구하고 이는 회사에 큰 문제였고, 마이크로소프트는 윈도우용 패러독스보다 몇 달 먼저 Access를 출시하여 마이크로소프트에 큰 마케팅 승리를 안겨주었다.
1990년, 볼랜드는 어셈블러로 작성된 DOS 및 윈도우용 내부 DBASE 클론 개발을 시작했으며, 이는 1992년에 출시될 예정이었다. 1992년 초, 애슈턴-테이트가 제품의 윈도우 버전 개발에 어려움을 겪고 있다는 것이 분명해졌고, 볼랜드는 계획을 변경하여 회사를 인수하고 내부 프로젝트를 공식적인 후속작으로 지정했다. 애슈턴-테이트 인수에는 인터베이스 rdbms가 포함되었고, Paradox/W가 Paradox 엔진뿐만 아니라 InterBase와도 함께 작동할 수 있어야 한다고 결정되었으며, 이는 InterBase를 중심으로 하는 IDAPI 엔진의 탄생으로 이어졌다.
인수는 또한 초점을 바꾸었다. 패러독스는 역사적으로 일부 시장에서 DBASE와 경쟁했으며, Paradox/W는 원래 개발자 중심 시장에서 경쟁력을 향상시키기 위해 설계되었다. DBASE가 인수된 후, 이는 더 이상 바람직하지 않았고, 사용 용이성 시장으로 초점이 전환되었다. 그러나 제품은 그 늦은 단계에서 이러한 초점에 맞게 변경될 수 없었으므로 (이는 이후 릴리스에서 발생했다) 제품이 초급 시장에는 다소 과도하게 복잡해졌다.
마이크로소프트의 첫 번째 데스크톱 데이터베이스 프로그램인 마이크로소프트 액세스는 동일한 시장을 잘 공략했으며, 1992년 11월 COMDEX에서 첫 선을 보였을 때 먼저 출시되었다. 볼랜드의 애슈턴-테이트 인수에 대응하여 마이크로소프트는 폭스프로를 인수하고 그 Rushmore 기술을 Access Jet Engine에 통합하여 성능을 크게 향상시켰다.
마이크로소프트 액세스는 최종 사용자 및 개발자가 구현하기 더 쉬운 많은 기능을 제공했다. 여기에는 QBE에서 Paradox의 필드 텍스트 태그 지정 대신 Windows의 필드 간 링크를 사용하는 더 직관적인 질의 인터페이스와 ObjectPAL보다 PAL과 더 유사한 Access Basic 프로그래밍 언어가 포함되었다. Access와 Paradox는 질의 결과 표시 방식에서 크게 달랐다. Access는 질의가 완료되기 전에도 레코드를 표시했고 출력 테이블 생성에 따른 오버헤드가 없었다. Paradox는 모든 레코드가 검색되고 ANSWER 테이블이 생성된 후에만 결과를 표시했다. 이러한 성능 차이는 대규모 데이터 세트에서 중요했으며 Paradox/W에 부정적인 영향을 미쳤다.
볼랜드의 저가형 쿼트로 프로 스프레드시트가 마이크로소프트 엑셀에 대항하여 출시된 것을 본받아,
마이크로소프트 액세스는 99달러 가격으로 첫 선을 보였다. 이는 Paradox DOS, Paradox Windows, DBASE의 전통적인 DBMS 가격인 약 799달러를 밑돌았으며, 이는 다른 어떤 회사보다 볼랜드에 부정적인 영향을 미쳤다.
볼랜드 경영진은 데스크톱 데이터베이스 시장의 85% 점유율을 가지고 있었음에도 불구하고 마이크로소프트와 마이크로소프트 액세스의 위협을 심각하게 과소평가했다. 그럼에도 불구하고 Paradox/W는 한동안 잘 팔렸다. 한편, 볼랜드는 애슈턴-테이트 인수와 관련하여 심각한 문제를 겪고 있었다. 많은 제품 라인이 단종되었고, 기업 재편 및 통합은 고통스러웠으며, 심지어 인수 근거의 핵심이었던 내부 DBASE 프로젝트는 기술적인 이유로 결국 취소되어 볼랜드는 매출 감소와 급히 윈도우용 DBASE를 개발해야 할 심각한 필요성을 겪게 되었다. 볼랜드는 다양한 제품에 필요한 여러 마케팅 전투를 치를 힘을 잃었다. 회사는 DBASE의 대체품을 기다리기로 결정했기 때문에 Paradox는 개발자들에게 최소한으로만 마케팅되었고, 이는 결국 1994년에 출시되었지만 회사에는 너무 늦었다.
설상가상으로, DOS용 DBASE 클론(FoxBase)은 DBASE를 거의 그대로 복사했지만, 이 제품의 윈도우 버전은 기존의 윈도우용 DBASE 모델 없이 개발되었다. DOS용 DBASE의 강점 중 하나는 다중 공급업체 지원이었는데, 이는 다양한 윈도우 xBase 제품에서 사라졌다. 볼랜드의 윈도우용 비주얼 DBASE는 마이크로소프트의 윈도우용 Foxbase 프로그램을 실행할 수 없었고 그 반대도 마찬가지였다. 파편화된 시장과 윈도우의 이점을 활용하기 위해 프로그램을 다시 작성해야 하는 상황에 직면하자, xBase 사용자들은 DOS에 사용했던 브랜드에 충성할 유인이 거의 없었다.
1995년, 마이크로소프트는 Access를 워드, 엑셀, 파워포인트와 함께 마이크로소프트 오피스 프로페셔널 스위트에 번들로 제공했다. 이는 독립형 제품에 대한 최종 사용자 데스크톱 데이터베이스 시장을 효과적으로 죽였다.
초급 사용자를 위한 사용 편의성 개선을 포함한 견고한 후속 버전에도 불구하고 Paradox는 시장에서 사라졌다. 이는 볼랜드 제품이 워드퍼펙트에 매각될 때 포함되었고, 워드퍼펙트가 금융 제품에 진출하면서 다시 재판매되었다. 작성 시점 현재, 윈도우용 Paradox, 워드퍼펙트, 윈도우용 쿼트로 프로는 모두 코렐 소유이며 그들의 오피스 스위트의 일부로 판매된다. 윈도우용 DBASE는 윈도우 시장에서 중요한 역할을 하기에는 너무 늦게 출시되었다. 그 무렵 대부분의 DBASE 프로그래머들은 매우 유사한 데이터베이스 도구인 마이크로소프트 FoxBASE로 이주했다. 볼랜드 자체는 InterBase/IDAPI 서버를 보유하고 델파이 도구에 노력을 집중했으며, 이는 수년간 데이터 지향 개발자 시장에서 영향력은 작지만 중요한 부분을 차지하게 했다.
패러독스 엔진.
패러독스 엔진은 DOS 프로그래머가 패러독스 데이터베이스를 사용할 수 있게 하는 미리 컴파일된 C 라이브러리였다. 마이크로소프트 퀵 C 및 터보 C 버전에서 사용할 수 있었다. 소스 코드는 공개되지 않았지만, 라이브러리에 포함된 모든 함수는 잘 문서화되어 있었다.
코렐 패러독스.
코렐은 1990년대 중반 패러독스를 개발하고 마케팅할 수 있는 특정 권한을 획득했으며, 1997년 코렐 패러독스 8을 출시했다.
패러독스는 코렐의 워드퍼펙트 오피스 스위트의 프로페셔널 버전에도 번들로 제공되었다. 이후 릴리스에는 오피스 프로페셔널 에디션 버전 9, 10, 11, 12, X3, X4, X5, X6, X7, X8, X9, 그리고 2020이 포함되었다. 그러나 2009년 X4용 패러독스 핫픽스 1 이후로는 업데이트되지 않았다. 모든 후속 릴리스는 11.0.0.676의 동일한 버전을 사용한다.
강력한 패러독스 사용자 기반이 있으며, 주로 Paradox 커뮤니티와 그 관련 뉴스그룹을 중심으로 한다. 2024년 7월 30일, 래리 디지오바니는 pnews.thedbcommunity.com 서버가 결국 읽기 전용이 되었다가 완전히 폐쇄될 것이며, TheDBCommunity라는 구글 그룹으로 대체될 것이라고 커뮤니티에 발표했다.
윈도우용 패러독스의 프로그래밍 언어인 ObjectPAL의 많은 팬이 있지만, PAL/DOS 스크립트는 쉽게 마이그레이션할 수 없었다. 객체 및 이벤트 모델이 완전히 달랐기 때문에 PAL을 사용하는 개발자들은 데이터베이스 애플리케이션을 완전히 다시 작성해야 했다.
1989년 BYTE는 패러독스 3의 사전 출시 베타 버전을 평가하면서 DBASE 클론이 아니면서도 "DBASE IV를 추월할 잠재력이 있다"고 말했다. 이 잡지는 패러독스가 "가장 고급 애플리케이션에 필요한 모든 기능을 갖추고 있으면서도 경쟁사와 달리 사용하기 쉬웠다"고 언급했다.
컴퓨터 인텔리전스는 1987년에 Ansa가 포춘 1000 PC 데이터베이스 시장의 3%를 차지하여 애슈턴-테이트와 Microrim에 이어 공동 3위라고 추정했다. 1990년 미국공인회계사협회 회원 설문조사에서는 응답자의 5%가 Paradox를 데이터베이스로 사용하고 있음을 발견했다.
알렘빅(alembic, , 에서 유래한 '컵, 비커'라는 뜻)은 액체를 증류하는 데 사용되는, 튜브로 연결된 두 개의 용기로 구성된 연금술 증류기이다.
완전한 증류 장치는 세 부분으로 구성된다.
또 다른 증류 용기인 레토르트의 경우 "캡"과 "쿠커빗"이 결합하여 하나의 용기를 형성한다. 안빅은 쿠커빗의 라스(아랍어 라스 raʾs는 "머리"를 의미한다)라고도 불린다. 쿠커빗의 액체는 가열되거나 끓여지며, 증기는 안빅으로 올라가 벽과 접촉하여 냉각되고 응축되어 주둥이를 통해 수신기로 흘러 들어간다. 알렘빅의 현대적 후손은 증류주를 생산하는 데 사용되는 포트 스틸이다.