EP1540475A2 - Systeme et procede destines a une repartition robuste des taches dans le temps a l'interieur d'un environnement de calcul en temps reel - Google Patents

Systeme et procede destines a une repartition robuste des taches dans le temps a l'interieur d'un environnement de calcul en temps reel

Info

Publication number
EP1540475A2
EP1540475A2 EP03793228A EP03793228A EP1540475A2 EP 1540475 A2 EP1540475 A2 EP 1540475A2 EP 03793228 A EP03793228 A EP 03793228A EP 03793228 A EP03793228 A EP 03793228A EP 1540475 A2 EP1540475 A2 EP 1540475A2
Authority
EP
European Patent Office
Prior art keywords
time
thread
threads
budget
interrupt
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP03793228A
Other languages
German (de)
English (en)
Inventor
Joe Smith
Aaron Larson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honeywell International Inc
Original Assignee
Honeywell International Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/223,395 external-priority patent/US7028815B2/en
Application filed by Honeywell International Inc filed Critical Honeywell International Inc
Publication of EP1540475A2 publication Critical patent/EP1540475A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues

Definitions

  • THIS APPLICATION IS A CONTINUATION OF CO-PENDING UNITED STATES PATENT APPLICATION SERIAL NUMBER 09/397,275 FILED SEPTEMBER 16, 1999, WHICH IS INCORPORATED HEREIN BY REFERENCE.
  • This invention relates generally to computer operating systems, and more particularly, to a real-time operating system which schedules multiple threaded application programs or processes.
  • Real-time computer operating systems typically supervise the execution of multiple concurrently executing applications (more precisely, applications which are repetitively scheduled and whose execution is interleaved). These real-time operating systems must provide a means for scheduling the applications, hi a 'hard' real time operating environment such as an aircraft cockpit, applications monitoring critical functions such as radio con -munication data and navigation information are typically executed together with applications monitoring other less critical functions. An operating system which supervises these multiple applications must ensure that the applications monitoring the less critical functions do not prevent the higher criticality applications from executing in a timely manner. In such an environment the computer operating system application scheduler must accomplish this by providing some form of time partitioning between the applications.
  • the application scheduling method of the present invention allows integration of critical real-time functions such as avionics display and control, while ensuring that the applications providing these functions are executed in a timely manner.
  • the present scheduling method multiplexes processor ('CPU') time amongst multiple application threads.
  • the time utilized by the operating system when executing on behalf of a thread is treated as being application processing time, rather than viewing the resultant processor time consumed as an operating system overhead.
  • a time budget is assigned to each thread.
  • the processor time consumed by the operating system when executing on behalf of a thread is charged back to the corresponding application as part of the application's time budget.
  • the amount of CPU time available to a thread during a given period of its execution is guaranteed by the present method, which efficiently apportions available CPU time by interrupt masking and thread budgeting.
  • Operating system overheads are thus accounted for accurately enough to determine a schedule for the applications which is enforceable by the operating system. Furthermore, the manner in which these overheads are accounted for permits run time creation and deletion of threads
  • interrupt response and other activities performed by the operating system that result from the passage of time must be accounted for.
  • An example is a response to the periodic system clock 'tick' that provides notice of the passage of time to the operating system.
  • Category 2 overheads (calls to operating system services) are a function of application behavior and cannot, in general, be accounted for in the manner of category 1 overheads. This is because application-induced overheads are not dependent solely on the passage of time; rather, in addition, they depend on the particular activities initiated by the applications.
  • Category 2 overheads can be subdivided into two types:
  • Overheads associated with category 2A activities are accounted for by the method of the present invention by viewing the time utilized as being application processing time, rather than viewing the resultant CPU time consumed as an operating system overhead.
  • the present method charges this CPU time back to the application as part of the application's time budget.
  • Mutex (MUTual Exclusion) services are system functions which pe ⁇ nit multiple threads to have synchronized access to application resources. For example, if an application uses multiple threads, and those threads share a common resource such as a data structure, mutexes can be used to ensure that only one thread can access the data structure at a given time.
  • the method of the present invention models category 2B blocking time by viewing a critical section as a mutex having the following properties: a) A priority ceiling one greater than the highest actual application priority; b) a period equivalent to the shortest period in the system being analyzed; and c) a duration equal to the duration of the time-critical section associated with the longest critical section not part of a category 1 overhead (the period of time when interrupts are disabled).
  • One embodiment of the present invention eliminates the need for tracking the interrupt inter-arrival rate by (1) activating a thread in response to an interrupt; (2) associating a time period with the interrupt; and (3) ensuring that during that period the aggregate CPU utilization resulting from handling as many interrupts as necessary does not exceed an allowed value.
  • This aspect of the invention if implemented, subsumes the category 2B overheads described above.
  • An alternative embodiment provides an interrupt with all of the properties described for a thread in the previous embodiment. In this case, the arrival of an interrupt and the termination of the interrupt handling are treated as a pseudo-thread activation.
  • Either of these (interrupt thread or pseudo-thread) solutions permits any number of interrupts associated with a specific interrupt to arrive during the associated period and also permits variability in processing time for each individual interrupt, as long as the aggregate used CPU utilization for the period does not exceed the allowed value for that particular interrupt.
  • This method greatly simplifies the enforcement of the application's budget because once the aggregate CPU time for the period has been exhausted, the interrupt can be masked until the end of the period associated with the interrupt. The act of leaving the interrupt masked when the CPU utilization has been exhausted is sufficient to ensure that no additional CPU time will be used by the interrupt handler and thus proper time partitioning is enforced.
  • FIGURE 1 is a diagram illustrating the scheduling of three application threads
  • FIGURE 2 is a flowchart showing the thread scheduling process
  • FIGURE 3 is a diagram illustrating the execution of an interrupt handler T and two application threads.
  • FIGURE 4 is a diagram illustrating timing events of interest for a single thread activation.
  • the present invention provides a mechanism for accounting for operating system overheads and processor interrupts in order to schedule multi-threaded application programs or processes in a manner which is enforceable by the operating system.
  • an application can have any number of threads. Every thread is associated with an application, which is considered to be the owner of the thread. The exact number of threads that can be active at any given time is a function of the CPU budget provided to the application, and the amount of CPU (processor) utilization allocated to the application's threads.
  • the thread scheduler of the present invention requires that every thread have a period associated with the thread.
  • the thread scheduler is rate monotonic; i.e., it assigns priorities based on the rate of the thread (shorter duration periods have higher priority).
  • each period be harmonic. For example, periods of 25ms, 50ms, and 75ms are multiples of a base period, but the 75ms is not harmonic, as it is not a multiple of 50ms.
  • Periods of 25ms, 50ms, and 100ms, however, are harmonic, and thus comply with the requirements of the present method.
  • a typical periodic thread operates in an infinite loop, performing the same logic over and over each period.
  • the present method allows a thread to call a thread relinquishment service that is intended to be called within that loop. The service suspends the thread until that thread's next period. This voluntary relinquishing of the CPU allows other threads in the system to execute.
  • Every periodic thread has a CPU budget that represents the maximum amount of time the thread can control the CPU's resources during its period.
  • the thread relinquishment service is called before that application's budget is used up.
  • the thread runs in a continuous loop until the budget is exhausted, at which point an interrupt is generated by an external timer. The operating system then suspends the thread until the start of its next period, thus allowing other threads in the system to execute on time.
  • Each thread contains a structure containing its thread execution status. In this structure are kept the initial CPU budget and the remaining budget after the last time the thread was suspended, and the PeriodCtr of the period in which the thread's budget was last replenished. Each rate is assigned a counter which is incremented each time that rate repeats. (This counter is referred to as the PeriodCtr).
  • the location of a given thread's thread execution status structure can be obtained by use of an appropriate system function.
  • the values stored in the thread execution status stTTicture can be reported by a status monitor process and can be used to help determine a suitable value for the thread's budget.
  • the method of the present invention implements Rate Monotonic Scheduling ('RMS') with a priority inheritance protocol.
  • the RMS method prioritizes periodic thread execution according to the thread's period. Higher rate threads have higher priority.
  • the priority inheritance protocol ensures that threads wishing to lock a mutex are not prevented from doing so by threads having a lower priority.
  • FIGURE 1 is a diagram illustrating the scheduling of three application threads, A, B, and C; and FIGURE 2 is a flowchart showing the thread scheduling process.
  • the present method is best understood by reference to Figure 1 in conjunction with Figure 2.
  • the periods employed in the present example are 5 units and 10 units.
  • Thread A has a period of 5 units and runs for 3 units each period.
  • Thread B has a period of 10 units and runs for 3 units each period.
  • Thread C has a period of 10 units and runs for 1 unit each period.
  • step 200 system parameters are initialized as follows.
  • a period timer is set to the base (minimum length) period for the threads being scheduled, which in this example, is 5 units.
  • the period timer generates an interrupt at the end of every minimum length period.
  • the active thread number n is initialized to a value of 1, which represents thread A, the highest priority thread in the present example.
  • Each thread counter ThreadCtr (n) 1 through N is set to 0 (where N is the number of threads; i.e. 3, in this case, and n represents the thread number); and each period counter PeriodCtr (p), 1 through P, is set to 1 (where P is the number of periods; i.e., 2, in this example, and p represents the specific period).
  • p has a value of 1 for the base period of 5 units, and a value of 2 for the 10 unit period.
  • every thread is assigned an initial budget.
  • the budget for thread n is established by setting the budget to a pre-established value which is determined as described below with reference to Figure 4. If the remaining budget of a thread were 'replenished' from the initial budget at every period boundary, the replenishment operation would have a run time overhead proportional to the maximum number of threads having that period. In systems where there is no period boundary skew, all threads would be replenished at one period boundary, resulting in an overhead which would be proportional to the total number of threads in the system. However, the replenishment must be an atomic operation, which would result in a critical section that is effectively unbounded (i.e., bounded only by the number of threads in the system), thus causing an arbitrarily large interrupt response latency.
  • the present method eliminates this unbounded interrupt response latency by distributing the occurrence of the times when the budget replenishment occurs. This is accomplished by associating a period counter (PeriodCtr) with each period p, and a "last executed counter value" (ThreadCtr), with each thread n. As shown in Figure 2, at step 210, the thread counter for thread B, ThreadCtr (1), is incremented to a value of 1. ThreadCtr (n) is thus set to the same value as PeriodCtr (p(n)) [where (p(n)) is period 1, thread n's period], to indicate that the budget for thread (n) has been replenished for its period.
  • PeriodCtr PeriodCtr
  • thread A After thread A has started executing, it continues execution until one of three events occur: (1) the thread invokes the thread relinquishment service, at step 240; (2) the thread budget is exhausted, at which point an interrupt is generated by a thread timer interrupt; or (3) a period timer interrupt (signaling that a period boundary has been reached) or other interrupt occurs.
  • event 1 or event 2 the thread is then suspended until the start of its next period.
  • event 3 the thread is suspended until the higher priority threads made ready by the interrupt have completed, after which, processing of the thread continues.
  • thread A execution is suspended by a thread timer interrupt at step 225, since thread A runs for 3 units in a 5 unit period.
  • n (the thread number) is set to a value of 2 for thread B (at this point the operating system executes a "context switch" to thread n).
  • the budget for thread B is replenished.
  • ThreadCtr (2) is set to a value of 1 (i.e., a value equal to the thread's period counter), to indicate that the budget for thread B has now been replenished for its period.
  • the undesirable, single, "unbounded" operation of replenishing N thread budgets is converted into N+l short, constant time operations: the incrementing of the period's counter, and N replenishment operations, one for each thread.
  • a period boundary is reached, and a period timer interrupt is generated, at step 245.
  • the period counters are incremented for each period having a boundary at that re-occurrence of the base period.
  • PeriodCtr (1) the period counter for the base period is incremented, but the period counter for the 10 unit period [PeriodCtr (2)] is not.
  • the thread timer for thread B [ThreadTimer (2)] is read, and the remaining time stored therein is saved as RemBudget (2), the remaining budget for thread B for period 2.
  • Thread A's budget is replenished, and thread A executes as described above, for steps 210, 215, and 220.
  • execution of thread A is suspended by a timer interrupt generated by thread A's timer [ThreadTimer (1)] at step 225, since thread A runs for 3 units in a 5 unit period.
  • n the thread number
  • n it is determined whether the budget for thread( «) has been replenished for its present period.
  • a time period is associated with an interrupt, and a thread is activated in response to the interrupt.
  • Category 2B overheads are enforced by ensuring that during that period the aggregate CPU (processor) utilization resulting from handling as many interrupts as necessary does not exceed a predetermined allowed value.
  • This method permits any number of interrupts associated with a specific interrupt to arrive during the associated period and also permits variability in processing time for each individual interrupt, as long as the aggregate used CPU utilization for the period does not exceed the allowed value for that particular interrupt.
  • the interrupt is masked until the end of the period associated with the interrupt. The act of leaving the interrupt masked when the CPU utilization has been exhausted is sufficient to ensure that no additional CPU time will be used by the interrupt handler and thus proper time partitioning is enforced.
  • FIGURE 3 is a diagram illustrating the execution of an interrupt handler T and two application threads, 'A' and 'B', all of which have an associated period of 20 units. As shown in Figure 3, thread A requires 6 time units to execute, and thread B requires 8 time units to execute, each 20 unit period. Therefore, threads A and B are scheduled for a total of 14 units in each 20 unit period, which leaves 6 units in each period remaining for handing interrupts.
  • Interrupt handler T can be viewed as (1) a thread which is activated in response to an interrupt request and treated exactly as the threads described with respect to Figure 1; or (2) it can be considered to be a 'pseudo- thread' having all of the properties of 'formal' threads including an associated time period and a time budget for the associated period. In either case, interrupt handler T can preempt the execution of other threads numerous times in a given period, provided that the sum of the duration of time of each execution of the interrupt handler does not exceed the time utilization (budget) reserved for the thread/pseudo- thread for any period.
  • interrupt handler T is masked at all times except when the interrupt handler thread is in a wait state in which it is waiting for the next occurrence of an interrupt. Therefore, if the interrupt thread is suspended, for example, by exceeding its time budget (or if the thread 'voluntarily' suspends itself), then the interrupt merely remains masked. This situation, wherein an interrupt is masked except when specifically waiting for the occurrence of an interrupt, ensures that the device associated with the interrupt is always in the proper state.
  • interrupt handler T i.e., thread/pseudo-thread T
  • a problem incurred by prior art scheduling methods is that computations of blocking time associated with mutexes assume that all the potential time used by a thread is accounted for. However, If a thread were to invoke an operating system function within t units prior to the time when the thread timer is scheduled to expire, and the invoked operating system function requires t or more units of time to execute, then the thread timer may actually become negative, thus preventing enforcement of proper thread scheduling. The reason the timer could become negative is that various critical operating system operations must be done atomically, and hence the interrupt associated with the thread timer is masked (ignored) during these 'critical sections'.
  • the present method sets the thread timer to a value which is less than the thread's remaining time budget, as explained in the following section.
  • FIGURE 4 is a diagram illustrating time relationships between the entities comprising a typical thread activation. Terms appearing in capital letters below correspond to the various thread budget segments in the diagram. As shown in Figure 4, when a thread timer is initially set for a given thread, the Timer Value to which the thread timer is set is determined by subtracting a Reserved Overhead value from the thread's total time budget. This Reserved Overhead corresponds to the amount of time consumed by longest critical section of instructions executed by the operating system during which interrupts are disabled (denoted as CRIT), plus the time that it takes to perform a thread context switch out of the presently executing thread (denoted as CTXout). It should be noted that the term 'longest critical section' is used herein to denote the longest critical section of instructions that does not perform a context switch to a different thread.
  • the thread is interrupted at a 'terminal' time equal to CTXout + CRIT time units before its budget is exhausted and the timer expires. Since a thread must always context switch to some other thread, the value for CTXout is correctly accounted for. However, the thread will not, in general, be invoking a critical section of operating system instructions when the timer interrupt arrives, and thus the CRIT time is potentially wasted. However, if a thread is activated multiple times in a single period, the "wasting" of the CRIT time is limited to the last activation of the thread, since the actual thread execution time is determined by reading the thread timer during the context switch.
  • T(w-r) Proper accounting of the time between the time (Tr) the timer is read (i.e., 'set' or 'reset') and the time (Tw) the timer is written (i.e., 'started') is shown as T(w- r), and is subtracted from the Thread Budget when determining the Timer Value.
  • the time T(w-r) is included in CTXout, and is thus included as part of the Reserved Overhead.
  • the time during which the timer is written defines the CTXin portion of the context switch that occurs while the timer is running on behalf of the thread, and hence is not subtracted as overhead.
  • This CTXin time period includes the time taken by the operating system to make the thread ready for execution, including the time spent to replenish the thread's budget, when such a replenishment operation occurs.
  • the Timer Value is thus the sum of CTXin and the Thread Execution Time.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Multi Processors (AREA)

Abstract

Système à répartition dans le temps qui permet de comptabiliser le temps de processeur utilisé par le système d'exploitation et employé par les moments de l'exécution d'une application dans un environnement en temps réel. On traite le temps utilisé par le système d'exploitation comme un temps de traitement des applications plutôt que de considérer le temps de processeur résultant utilisé comme un temps supplémentaire du système d'exploitation. Chaque application est constituée d'une ou plusieurs unités d'exécution. Un budget en termes de temps est attribué à chaque unité d'exécution et à chaque interruption. Le temps de processeur utilisé pendant l'exécution de la part d'une unité d'exécution ou d'une interruption est 'refacturé' à l'application ou à l'interruption comme faisant partie du budget de temps de l'application. Le temps supplémentaire et les interruptions du processeur sont ensuite comptabilisés avec précision pour déterminer l'horaire des applications à appliquer par le système d'exploitation pendant les moments de l'exécution.
EP03793228A 2002-08-20 2003-08-15 Systeme et procede destines a une repartition robuste des taches dans le temps a l'interieur d'un environnement de calcul en temps reel Withdrawn EP1540475A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US223395 2002-08-20
US10/223,395 US7028815B2 (en) 2001-08-23 2002-08-20 Double-wrap brake band apparatus
PCT/US2003/026215 WO2004019205A2 (fr) 2002-08-20 2003-08-15 Systeme et procede destines a une repartition robuste des taches dans le temps a l'interieur d'un environnement de calcul en temps reel

Publications (1)

Publication Number Publication Date
EP1540475A2 true EP1540475A2 (fr) 2005-06-15

Family

ID=31946273

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03793228A Withdrawn EP1540475A2 (fr) 2002-08-20 2003-08-15 Systeme et procede destines a une repartition robuste des taches dans le temps a l'interieur d'un environnement de calcul en temps reel

Country Status (3)

Country Link
EP (1) EP1540475A2 (fr)
AU (1) AU2003289970A1 (fr)
WO (1) WO2004019205A2 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9361156B2 (en) 2005-03-14 2016-06-07 2236008 Ontario Inc. Adaptive partitioning for operating system
CA2538503C (fr) 2005-03-14 2014-05-13 Attilla Danko Ordonnanceur de processus a partitionnement adaptatif des files de processus
US8245230B2 (en) 2005-03-14 2012-08-14 Qnx Software Systems Limited Adaptive partitioning scheduler for multiprocessing system
US8387052B2 (en) 2005-03-14 2013-02-26 Qnx Software Systems Limited Adaptive partitioning for operating system
CN103984596B (zh) * 2014-05-19 2017-06-20 上海微小卫星工程中心 一种星载软件的调度方法及装置
CN106763304B (zh) * 2016-12-02 2019-11-22 武汉船用机械有限责任公司 一种带式刹车装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5386561A (en) * 1992-03-31 1995-01-31 International Business Machines Corporation Method of integrated system load control through dynamic time-slicing in a virtual storage environment
US6754690B2 (en) * 1999-09-16 2004-06-22 Honeywell, Inc. Method for time partitioned application scheduling in a computer operating system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2004019205A3 *

Also Published As

Publication number Publication date
WO2004019205A3 (fr) 2005-01-06
AU2003289970A8 (en) 2004-03-11
WO2004019205A2 (fr) 2004-03-04
AU2003289970A1 (en) 2004-03-11

Similar Documents

Publication Publication Date Title
US7207042B2 (en) System and method for robust time partitioning of tasks in a real-time computing environment
US7302685B2 (en) Methods and apparatus for sharing slack in a time-partitioned system
US7140022B2 (en) Method and apparatus for slack stealing with dynamic threads
CA2538503C (fr) Ordonnanceur de processus a partitionnement adaptatif des files de processus
Lin et al. Improving soft real-time performance through better slack reclaiming
US20030061260A1 (en) Resource reservation and priority management
Fidge Real-time schedulability tests for preemptive multitasking
US20050015766A1 (en) Time deadline based operating system
WO2002054238A2 (fr) Procedes et appareil de partage d'ecart dans un systeme de repartition de temps
WO2004019205A2 (fr) Systeme et procede destines a une repartition robuste des taches dans le temps a l'interieur d'un environnement de calcul en temps reel
Wellings et al. Cost enforcement and deadline monitoring in the real-time specification for Java
Binns A robust high-performance time partitioning algorithm: the digital engine operating system (DEOS) approach
Zouaoui et al. CPU scheduling algorithms: Case & comparative study
Migge et al. Timing analysis of compound scheduling policies: Application to Posix1003. 1b
Zhang et al. Middleware support for aperiodic tasks in distributed real-time systems
Mancina et al. Enhancing a dependable multiserver operating system with temporal protection via resource reservations
Zhang et al. End-to-end scheduling strategies for aperiodic tasks in middleware
Lyons et al. It's time: OS mechanisms for enforcing asymmetric temporal integrity
EP1433054A2 (fr) Procedes et appareil de detournement de marge avec des fils dynamiques
CN118093140A (zh) 一种内核级时间触发调度方法及装置
Holenderski Real-time system overheads: A literature overview
Mancina Operating Systems And Resource Reservations
Liu et al. An Open Environment for Real-Time Applications
Sommer Temporal Protection in Dreams
Memeti et al. Operating System Support for Multimedia Applications and Processor Capacity Reserves

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20050302

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

17Q First examination report despatched

Effective date: 20070509

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20071120