이 글의 첫 번째 부분은 AUTOSAR 표준에서 멀티코어와 관련해 확장된 부분에 대한 전체적인 설명을 담았다. 또 소프트웨어의 분산 최적화를 위한 전략들을 비교해 볼 수 있는 기반이 되는 실험적인 설정을 소개했다. 두 번째 부분에서는 이제 세 가지 구체적인 분산 전략에 대해 논하고, 실제적인 시나리오상에서 엔진 제어기를 위한 소프트웨어의 예를 들어 이들을 평가해 볼 것이다.



캐스린 샤이데만(Kathrin Danielle Scheidemann) BMW Car IT GmbH
2008년 이후 BMW의 Car IT GmbH에서 임베디드 멀티코어 분야의 R&D프로젝트를 책임지고 있다. 이전에는 맨프레드 브로이(Manfred Broy) 박사밑에서 임베디드 시스템을 위한 테스트와 신뢰성 전략에 대해 연구를 했다.

미카엘 크나프(Michael Knapp) BMW Car IT GmbH
2008년 이후 BMW의 Car IT GmbH에서 일하고 있다. 2009년부터는 임베디드 멀티코어 분야의 R&D에 관여하고 있다. 이전에는 뮌헨 기술대학에서 정보학을 공부했다.

클라우스 스텔바그(Claus Stellwag) Elektrobit GmbH
FAU Erlangen에서 운용체제에 초점을 맞춰 정보학을 공부했다. EB(Elektrobit)에 15년 근무했으며 ECU분야의 소프트웨어 아키텍처를 책임지고 있다. 이 활동과 관련해 해당 AUTOSAR 워킹 그룹에서 활발히 활동하고 있다.


Release 4.0에서 AUTOSAR는 최초로 임베디드 멀티코어 프로세서에서 소프트웨어 분산 실행을 지원하기 위한 표준을 제공한다. 서로 다른 컨트롤러들 간 또는 심지어 하나의 컨트롤러에 있는 프로세서들 간에 소프트웨어를 분산하는 것에 비해  컴퓨터 코어들 간 소프트웨어를 분산 시에는, 통신으로 인한 오버헤드와 디자인의 한계가 작아지므로 더 많은 자유가 보장된다. 한 가지 어려운 점은 멀티코어 플랫폼의 컴퓨팅 파워를 최적으로 사용할 수 있게 이같은 자유를 잘 활용하는 것이다. 이 글의 첫 번째 부분은 AUTOSAR 표준에서 멀티코어와 관련해 확장된 부분에 대한 전체적인 설명을 담았다. 또 소프트웨어의 분산 최적화를 위한 전략들을 비교해 볼 수 있는 기반이 되는 실험적인 설정을 소개했다. 두 번째 부분에서는 이제 세 가지 구체적인 분산 전략에 대해 논하고, 실제적인 시나리오 상에서 엔진 제어기를 위한 소프트웨어의 예를 들어 이들을 평가해 볼 것이다.

개요
일반적으로 실시간 시스템에서 실행 유닛의 분산 목적은 가능한 가장 비용 효율적인 하드웨어를 가지고 모든 가능한 실행 조건 하에서 소프트웨어 컴포넌트들(SWCS)의 모든 타이밍 요구조건을 만족시키기 위한 것이다. 어떤 구성이 모든 실시간성을 충족시킬 수 있는 것을 시현해 보이는 것도 어렵지만[8], 충분히 큰 시스템에 대해서 최적 솔루션을 효율적으로 계산하는 것 또한 어렵다. 따라서, 수동적인 분산 최적화는 시간이 매우 많이 소요되며, 리소스를 최적으로 활용할 수 있게 되는 수준에 도달하는 것이 보장되지도 않는다.
이러한 이유로 인해, Infineon AG, Elektrobit GmbH, BMW CarIT GmbH 등 세 회사는 기본적으로 다른 세 가지의 전략을 검토해 보기 위해 드라이브 도메인에서 이용되는 실험적인 셋업을 사용했다. 이는 툴을 사용해 멀티코어나 멀티프로세서 플랫폼에 실행 유닛을 분산하는 것을 최적화 시키는 것이다:

(1) 실행 단위(Runnable)들의 자유 분산
(2) 실행 단위 그룹들의 분산: 데이터 흐름에 따라 각 태스크에 이전에 할당된 실행 단위별로 그룹화
(3) 장벽(barrier) 아키텍처에서 병렬화: 이전에 하나의 단일 태스크로부터의 실행 단위들은 동기화 돼 실행되는 태스크들에 걸쳐 분산된다.

설정(Setup)
서로 다른 분산 시나리오들을 유연하게 실험하기 위해 한 덩어리의 소프트웨어로 존재하는 엔진 제어기 소프트웨어 툴을 사용해 다수의 AUTOSAR 소프트웨어 컴포넌트들로 나눴다[1]. 소프트웨어 컴포넌트들은 서로 다른 코어들에서 동작하는 OS의 응용 프로그램으로 할당돼, 프로토타입 멀티코어 AUTOSAR 기반 소프트웨어와 상호 RAM을 공유하는 듀얼 프로세어 하드웨어에서 실행됐다. 하드웨어 플랫폼은 Matlab/Simulink에서 시뮬레이션 되는 로드 모델과 함께 통합됐다[3]. 그림 1은 이러한 설정을 보여준다.
초기 소프트웨어의 내부 동작에 따라 약 200개의 실행 단위를 정의하고 주기적으로 또는 이벤트에 의해 트리거 되는 다양한 우선순위를 갖는 다중 태스크들을 사용해 특정 순서로 모델링 했다. 태스크들의 스케줄링은 협업적인데, 다시 말하면 태스크들은 미리 정한 지점에서만 인터럽트 될 수 있다는 뜻이다. 실행 단위들 사이의 통신은 전역 변수를 사용해 이뤄졌다. 서로 다른 실행 단위들에 의해 호출되는 함수들은 매개 변수를 통해 또는 전역 변수를 기반으로 동작했다. 타이밍 요건은 제한적으로 실현됐는데 태스크들의 다중 활성화(activation)는 불가능하고 한 태스크 내의 모든 실행 단위들은 한 사이클 내에 완전히 처리돼야 했다.
분산되지 않은 원래 소프트웨어는 프로세서들 중의 어느 하나에 일부 부하(약 6%)만 가하므로 최적화의 목적은 두 개의 프로세서들이 비슷한 부하를 경험하도록 실행 유닛을 분산하며, 분산으로 인해 발생하는 코어 간의 통신과 분산 동기화 등을 위한 추가 비용을 최소화 하는 것으로 정했다.
(1) 실행 단위들의 자유 분산 
실행 단위들의 자유 분산에서는 모든 실행 단위들은 n 개의 서브셋(각 컴퓨터 코어 당 하나) 으로 나눠지는데, 어느 기간에 최악의 경우의 실행 시간들의 합이 모든 서브셋에 대해 동일하도록 한다. 더욱이 추가된 코어 간 통신비용을 낮추기 위해 실행 그룹들 간의 통신양이 최소화 돼야 한다. 이러한 문제에 대한 기술은 “balanced graph cut” 문제(예를 들면 [4])에서 볼 수 있는데, 이 문제에서는 서브셋들 간의 선분들의 숫자(또는 선분 무게의 합)가 최소화 되도록 하면서도 노드들의 숫자(또는 노드 무게의 합)가 가능한 균형을 이루도록 그래프 상의 노드들의 집합을 파티션들로 분할한다. 이 글의 경우에 비추어 보면 실행 단위들은 노드들로 주어진 시간 간격 동안의 최악의 경우에 해당하는 실행 시간에 의해 가중된다. 노드들 간의 선분은 실행 단위들 사이의 데이터 흐름으로부터 얻어진다. 선분은 공유된 데이터 오브젝트들의 숫자들과 접근 빈도에 따라 가중된다. 그림 2는 이러한 전략을 그래픽으로 보여준다.
동일한 포인터를 사용하는 실행 단위들을 분리하는 것을 막기 위해 이러한 실행 단위들 사이의 선분은 매우 높이 가중되었다. 여기에 기술된 경우에 대한 연구에서는 오픈소스 라이브러리인 METIS[2]가 이같은 문제에 대한 해결방안을 찾는데 사용됐다.
원래 소프트웨어에서는 실행 단위들은 인터럽트 되지 않아, 심지어 실행 시간 동안의 서브 함수까지도 포함한 전역 변수에 대한 배타적인 접근이 보장됐다. 다시 말하면 실행 단위들의 값은 외부에서 변경될 수 없다. AUTOSAR 통신 패러다임에서 기존의 프로그래밍 컨셉을 구현할 때는 전역 변수를 사용하는 서로 다른 코어들에서 동작하는 실행 단위들 사이의 통신은 간접적이고 버퍼링이 없는 송신자-수신자 통신을 이용해 모델링된다. 이 경우 실행 단위가 작동하기 전에, RTE는 읽은 값에 대한 지역 복사본을 만들고, 작동 후 계산된 값들을 해당되는 수신자를 위한 버퍼에 기록해 실행 단위가 동작하는 대상이 되는 데이터 버전이 작동 중에 변경 될 수 없도록 한다.
어려움은 전역 변수를 가지고 일하는 실행 단위들에 의해 호출되는 함수들의 구현에서 일어난다. 이러한 함수들은 직접 이러한 전역 변수들에 접근할 수 없는 대신 추가적인 파라미터로 전역 변수의 지역 복사본에 대한 포인터를 받도록 자동으로 변경된다.
이 방식으로 병렬화 되지 않은 경우에서와 마찬가지로 실행 중에 외부로부터 실행 단위가 작업하고 있는 데이터 버전을 변경할 수 없도록 하는 것이 보장될 수 있다. 단일 코어에서처럼 보다 높은 우선순위를 갖는 태스크에 의해 업데이트 되는 데이터는 보다 높은 우선순위의 태스크가 마지막으로 활성화된 순간의 가장 최근 값이 된다.
전체 시스템의 동작은 병렬성으로 인해 여전히 바뀔 수가 있다: 원래 소프트웨어에는 하나로 결정된 실행 순서가 태스크 내의 실행 단위 사이사이에서 데이터 흐름으로 정의된다. 실행 단위의 임의 분산으로 더 이상 그렇지 않다; 서로 다른 코어에 있는 실행 단위들의 실행 순서는 추가적인 동기화가 없다면 하나로 결정될 수가 없다.
송신자-수신자 통신에서 동일 데이터의 복수 송신자가 있다면 누락 업데이트가 발생할 수도 있다. 어느 실행 단위에서 보내진 메시지는 만일 또 다른 실행 단위가 자신이 가지고 있는 업데이트 된 값을 보내기 전에 다른 코어에 있는 예전 값의 지역 복사본에 작업을 하고 있다면 잃어버리게 된다.
본래의 소프트웨어에서는 태스크 내의 서로 다른 실행 단위에 의해 읽혀진 데이터는 만일 높은 우선순위의 태스크에 의해 써졌다면 그 태스크의 실행 중에만 변경될 수 있도록 보장된다. 이러한 가정은 분산 시나리오에서는 더 이상 성립되지 않는데 더 낮은 우선순위의 태스크들이 이제 더 높은 우선순위의 태스크들과 동시에 활성화 되어 있을 수 있기 때문이다. 하지만, 이러한 상황에서 개발자들은 이것을 중요하지 않은 것으로 보는데, 실행 단위들을 여러 태스크에 분산시키는 것이 개발 과정에서 상당히 뒷부분에 결정되기 때문으로 이러한 타입의 데이터 일관성에 대한 어떠한 가정도 필요하지 않다.
여기서 검토되는 엔진 제어기를 위한 실행 유닛 분산의 최적화 결과는 총 29개의 송신자-수신자 포트들을 갖는 두 개의 최종 소프트웨어 컴포넌트들 사이에 대한 인터페이스였다.  코어 1은 단일 코어에서 전체 소프트웨어를 실행하던 것에 비해 부하의 31%가 경감될 수 있었다. 전체 작업 부하는 22% 만큼 증가했는데, 그것은 한편으로는 RTE 기능의 다소 증가된 비용에 의해 설명될 수 있지만, 다른 한편으로는 듀얼 프로세서 보드 구조에서 공유 RAM에 대한 접근이 코어 내부의 RAM에 대한 접근보다 훨씬 더 느리다는 사실로부터 강한 영향을 받은 것이다. 데이터의 일관성을 보장하기 위해 RTE는 스핀락(spinlock)을 사용하는데, 그것은 현재의 설정에서는 비현실적으로 느리다. 따라서 실제의 멀티코어 하드웨어에서는 더 작은 오버헤드를 기대할 수 있다. 코어 2에 대한 부하는 코어 1에 대한 부하의 77%였다.
여기서 논의된 첫 분산 전략은 아래 제시된 전략들에 비해 성능 분석에서 비교적 좋은 결과를 보였다. 하지만 이 전략은 원래의 아키텍처에서 제공되는 보장(예를 들면, 태스크 내의 실행 단위들 사이에서 확정된 데이터 흐름)들을 병렬 케이스에서는 더 이상 얻을 수 없다는 심각한 단점을 가지고 있다. 만일 원하지 않는 시스템 동작에 이르는 것이 배제되지 않는다면 이러한 분산 전략은 사용될 수 없다.
(2) 실행 그룹의 분산
실행 단위의 자유 분산의 단점을 피하는 한 가지 옵션은 원래 동일한 태스크에서 처리되고 상호 데이터 흐름이 있는 실행 단위들을 그룹으로 묶고 이러한 그룹들의 분산을 최적화 하는 것이다. 그림 3은 이러한 전략을 형상화한다.
이 분산 전략은 원래의 아키텍처에서 상호 간에 데이터 흐름이 존재하는 원래의 태스크에 있는 실행 단위 간에 정의된 데이터 흐름을 얻게 한다. 그러나 만일 서로 다른 코어들에서 서로 다른 우선순위의 실행단위들이 동일한 데이터 오브젝트들의 송신자들이라면 “누락된 업데이트”가 여전히 발생할 수 있다. 이것은 만일 동일한 데이터의 송신자들인 실행 단위 그룹들이 최적화되기 전에 통합된다면, 즉 그것들이 함께 분산된다면 예방될 수 있다.
여기서 검토된 엔진 제어기에 대한 이같은 분산 전략은 20개의 송신자-수신자 포트들을 갖는 두 개의 소프트웨어 컴포넌트들 사이의 인터페이스를 가져왔다. 코어 1의 부하는 13%가 줄어들었다. 코어 2에 대한 부하는 코어 1에 대한 부하의 56%였다. 전체 작업 부하는 병렬화 되지 않은 소프트웨어에 비해 29% 증가했다.
따라서 두 개의 코어에 작업 부하를 분산하는 것은 실행 단위의 자유 분산의 경우보다 전체적으로 덜 균형을 갖게 되는데, 이것은 최적화에서 감소된 자유도로부터 기인한 것이다. 코어 간 통신에 의한 오버헤드가 더 많다. 그러나 실행 단위의 자유 분산에 비해 이 전략은 상호 간에 데이터 흐름이 있는 원래의 태스크에 있는 실행 단위의 실행 순서가 결정적이라는 장점을 제공한다.

(3) 장벽(Barrier) 아키텍처에서 병렬화
앞서 살펴본 것처럼 동일한 우선순위를 갖는 실행 단위 사이의 데이터 흐름 때문에 추가적인 동기화 없이는 그것들의 분산은 매우 제한적이다. 두 개의 코어들을 가지고도 코어 1은 부하의 13% 만을 줄일 수 있었다. 두 개 이상의 코어들에 실행 단위들을 분산할 때의 작업 부하는 코어들 간에 균형이 보다 덜할 것이다.
더 좋은 분산 균형을 위한 하나의 옵션은 설명한 것처럼 동일한 우선순위와 상호 간의 의존성이 있는 실행 단위들을 함께 두지 않으며, 오히려 태스크들을 동기화하는 것이다. 필요한 경우 그 태스크들의 실행 단위들은 서로 다른 코어들에서 실행된다. 이것들은 장벽 아키텍처를 갖고 달성된다. 여기에서 각각의 원래 태스크들에 대해 각 코어에 대한 해당 태스크들이 있다. 각 코어들에 원래 태스크의 실행 단위가 분산된다. 만일 필요하다면, 태스크들이 상호에 대해 대기하는 동기화 지점(장벽 예제 [6])이 삽입된다.
실행 단위들의 분산은 각각의 개별 태스크들에 대해 별도로 최적화된다. 그 목적은 원래 태스크의 실행 단위들을 태스크들의 실행 시간이 최소로 유지되는 방식으로, 결과적으로 만들어지는 n개의 병렬 태스크들에 분산하는 것이다. 만일 실행 단위들 사이의 데이터 흐름이 서로 다른 코어 간에 발생한다면 실행 순서는 동기화 지점에 의해 제어된다. 그림 4는 이러한 분산 전략을 그래픽 형태로 보여준다.
단일 코어 아키텍처가 제공하는 보장들을 모두 유지하기 위해서는 상호 간에 해당하는 태스크들을 모든 코어에서 동시에 실행하도록 보장해야 한다. 이것은 각 태스크의 시작점에 동기화 지점이 삽입되는 것을 필요로 한다. 단일 코어 아키텍처의 협력 스케줄링은 태스크가 인터럽트 할 수 있도록 보장한다. 병렬의 경우에도, 이들을 보존할 수 있도록 하는 동기화 지점들 사이의 시간차는 그 태스크의 집중적인 실행 단위들의 최대 실행 시간을 넘을 수 없다. 추가로 협력 스케줄링을 모델링하기 위해 각 동기화 지점에서 스케줄러가 호출된다.
코어 간 통신을 최소화하는 것은 이 분산 정책에서 최적화의 직접적 목적은 아니다. 데이터 일관성은 아키텍처에 의해 이미 보장된다. 때문에 전역 데이터의 지역 복사본의 생성과 스핀락에 의한 전역 변수의 보호와 같은 수단들은 제거될 수 있다. 공유 메모리에 대한 접근이 지역 메모리에서 보다 훨씬 더 많은 오버헤드를 초래하지 않는다는 가정 하에 얼마나 많은 실행 단위들이 전역 변수들에 접근하는지, 그리고 얼마나 자주 그런 일이 발생하는지는 상관이 없다. 물론 이러한 가정의 타당성은 사용되는 하드웨어의 아키텍처에 매우 의존적이다. 예를 들면, 그림 4의 분산에서 코어 간 통신의 양은 또한 그림 3의 분산에서보다 상당히 많다.
이 분산 전략에서도, 충분히 큰 응용에 대해서는 최적 해법이 효율적으로 계산되지 않는다[5]. 그러나 분산은 발견적 학습, simulated annealing[4]과 같은 최적화 절차, 또는 선형 문제 해법[7] 등을 통해 최적화 될 수 있다. 후자는 실제적인 해법이면서도 발견된 솔루션의 품질이 얼마나 좋은가, 다시 말하면 최적인가 또는 더욱 확대된 최적화에서 얼마나 많은 향상이 가능한가에 대한 서술이 만들어지는 장점이 있다.
검토 과정에서는 분산을 위해 발견적 학습이 사용됐다. 이 발견적 학습(heuristic)은 분산될 수 있는 실행 단위들에 대한 리스트를 유지 관리했다. 이것들은 나중에 병렬로 실행되는 태스크들에 분산됐다. 실행 단위들은 병렬이 아닌 경우에서 읽은 데이터를 쓰는 그들 이전에 실행되는 모든 실행 단위들이 동일한 코어에 할당되거나 또는 마지막 동기화 지점 전에 다른 코어에 분산될 수 있다.
모든 분산 가능한 실행 단위들이 분산되었지만, 마지막 동기화 지점으로부터의 총 실행 시간이 태스크에서 가장 계산이 많은 실행 단위들의 최대 실행 시간을 넘기 전에 동기화 지점이 삽입된다. 만일 여기에서 검토된 엔진 제어기에 이러한 발견적 학습이 사용되면, 코어 1은 동기화 자체가 추가 시간을 필요하지 않는다는 가정 하에서 이론적으로 부하의 18%를 줄일 수 있다. 부하에 대해 이론적으로 도달할 수 있는 감소량은 설명된 발견적 학습법을 사용하는 것보다 다른 최적화 방법들을 사용해 어떤 상황에서는 상당히 향상될 수 있다. 두 개의 코어에 대한 부하는 이 전략에서는 항상 동일하다. 장벽에 대해서는 AUTOSAR에서 표준 API가 제공되지 않았다. 하지만 제공되는 스핀락을 사용하는 복합 디바이스 드라이버로 구현될 수 있다.
그러나 이 시나리오에서 실제로 측정된 코어 1에 대한 부하는 병렬이 아닌 경우에서의 부하보다 높았다. 이것은 현재 구현에 사용된 하드웨어에서 동기화가 매우 느리다는 것에 의해 설명될 수 있다. 만일 동기화가 실험적으로 제거된다면 실행 단위들의 자유 분산에 의해 달성할 수 있는 것에 상응하는 부하 감소를 얻을 수 있다. 인터페이스는 485개의 송신자-수신자 포트들을 포함한다. 이 분산 시나리오에서 사용된 RTE의 구현은 데이터 오브젝트에 대한 배타적인 접근이 이미 동기화에 의해 보장되므로 스핀락을 사용해 데이터 오브젝트에 접근하는 것을 보호하지 않는다는 것에 주목할 필요가 있다.
만일 동기화가 여기에 설명된 설정에서처럼 매우 시간 소모적이라면, 좀 더 적은 수의 동기화 지점을 허용하고 대신에 해당하는 태스크들에서 덜 균형잡힌 실행 시간으로 만족하는 것이 실용적이다. 예를 들면, 최적화 문제를 정수와 분수를 포함하는(mixed integer) 문제[7]로 공식화(formulating)함으로써 동기화에 필요한 최소 시간을 고려할 수 있는데, 이에 따라 그것들은 최적화를 실제에 적용할 때 즉각 사용될 수 있다.
장벽 아키텍처에서 소프트웨어의 병렬화는 높은 수준의 병렬성을 도달하는 옵션을 제공한다. 그러나 소프트웨어 아키텍처가 얼마나 많은 병렬성을 허용하는가, 그리고 서로 다른 동작 상황에서 실행 단위의 실행 시간이 얼마나 많이 변화하는지에 의존해 최악의 경우에 대한 최적화가 장벽에서 활성화된 기다림 때문에 보통의 상태에서는 낭비되는 많은 컴퓨팅 시간을 초래할 위험이 있다. 이것은 장벽을 사용하는 대신에 만일 모든 코어에서 실행 가능해진 각 서브 태스크가 동기화 지점에서 활성화 되면 예방될 수 있다. 그러나 이 경우 태스크의 활성화 자체가 장벽과 관련된 동작보다 더욱 시간 소모적이 될 수 있다.

요약
4.0 버전 발표 이래, AUTOSAR 표준은 프로세서 내의 다른 컴퓨터 코어에 실행 유닛을 분산하는 옵션을 제공한다. 여기에 제시된 학습 케이스에서 한 덩어리로 된 소프트웨어는 처음에 AUTOSAR에 기반을 둔 서로 다른 분산 시나리오를 구현하고 비교하기 위해 소프트웨어 컴포넌트들로 분산되어야 했다. 충분히 깊은 모델링, 즉 더 이상 나눌 수 없게 작은 소프트웨어 컴포넌트들을 가지고 소프트웨어들 간에 AUTOSAR에 의해 달성되는 통신의 추상화조차도 유연하게 결정되는 분산을 허용한다. 서로 다른 분산 시나리오를 구현하는데 있어 유연성은 시스템의 실행 행태를 최적화하기 위한 기본적인 선행 요건이다. 하지만 앞으로 멀티코어 플랫폼의 컴퓨터 성능를 효과적으로 사용하기 위해서는 이것 하나만으로는 부족하다.
가능한 분산 시나리오의 숫자와 주어진 문맥에서 분산 실행 시 행태에 대한 많은 영향을 감안하면 시스템 통합자의 경험에 기반을 둔 완전 수작업에 의한 최적화는 곧 한계에 도달해 하드웨어 성능이 이상적으로 활용되지 않는 상황에 이를 것이다. 따라서 최적화에서의 도구 지원은 필수적이다.
여기에 세 가지 다른 접근 방법이 소개되었다. 제시된 측정값은 구체적인 응용 소프트웨어, 사용된 베이스 소프트웨어, 그리고 사용된 하드웨어에 따라 다르다. 적합한 분산 전략은 또한 특정 문맥에 무척 의존적이다. 표 1은 여기에 비교된 세 가지 전략들의 선결 요건에 대한 요약 설명이며 각 전략에 적합한 응용 시나리오를 알려주는 몇 가지 경험 법칙이다.
여기에 기술된 연구에서는 소프트웨어의 분산과 AUTOSAR 기본 소프트웨어의 구현이 최적화 되었다. 하드웨어, 하드웨어 설정, 응용 소프트웨어의 설계와 구현은 고정된 것으로 가정했지만 실제로는 최적화 과정에서 활용할 수 있는 수많은 추가적 자유도가 있다. 앞으로 컴퓨팅 파워가 가능한 가장 효과적인 사용만이 목표가 되지는 않을 것이다. 전력 사용과 기능의 신뢰성은 최적화 과정에서 다뤄질 또 다른 척도의 한 예다. 다양한 측면을 고려할 수 있고 시스템 통합자에게 실용적인 방법으로 디자인 공간을 탐색할 수 있는 도구를 제공하는 접근법이 가장 이상적으로 가능한 시스템에 도달하기 위해 바람직 할 것이다. 현 시점에서는 과학적인 관점에서조차 매우 흥미로운 많은 질문들이 답을 기다리고 있다.