Towards an Application of ModelBased Codesign An Autonomous, Intelligent Cruise Controller

Cruise Controller

S. Schulz and J.W. Rozenblit K. Buchenrieder

Dept. of Electrical and Computer Engineering Siemens AG

The University of Arizona ZFE T SE 5 Tucson, Arizona 85721-0104 Otto-Hahn-Ring 6

USA 81739 Munich

{sschulz|jr@ece.arizona.edu} buchen@zfe.siemens.de

Abstract

In this paper, the domain of automotive safety isaddressed. A specific application, i.e., autonomous,intelligent cruise controller, is selected. Model-basedtechniques which facilitate implementation independentspecification and design of such a system are discussed.A set of systems requirements, the underlying object andbehavioral models are given. In conclusion, postulatesare discussed for the physical realization of thepresented application.

1. Introduction

In the last decade, we have witnessed a sizable growthin the application of electronics in automotive industry.Initial applications ranged from electronic fuel injectiondevices to motor control units. With the advent of morepowerful microprocessors, a new generation of devicesis emerging. They are intended to improve safety of theautomobile and its environment. A comparison of theautomotive traffic with its counterparts, i.e., air and railtransportation shows that the automobile-based mode oftransportation is the least controlled and structured.Therefore, it is imperative that passive and activedevices be developed that provide driver assistance andserve as collision deterrents.

In this paper, we categorize the majors aspects ofautomotive safety, select a specific application, i.e., anautonomous, intelligent cruise controller, and proposemodel-based techniques for a realization of such adevice.

Germany

2. Model-based codesign

A multitude of codesign techniques and methodologiesare employed in academic and commercialenvironments [7,8,9,12,18,19]. A common trendappears to be emerging in which a clear shift in designand development paradigms is occurring. Initialapproaches would foster immediate partitioning intohardware (HW) and software (SW) components, pursueHW and SW development threads in isolation from eachother, and often place a stronger emphasis on hardwarethan software [1,11,12]. Those trends stem from certainmisconceptions regarding the design of heterogeneoussystems, namely, the beliefs that HW and SW can bedeveloped separately, that inadequacies in the hardwarecomponents can be compensated by software revisions,and that the integration of subsystems should bepostponed until the end of the design cycle. Numerousauthors point to the deficiencies of the traditionalcodesign frameworks [1,2,5,9,12]. They stronglyadvocate a process that fosters the integration of theHW and SW perspectives. Thus, a unified representationis needed for modeling a system independently of itsimplementation in hardware or software. A number ofmodeling representations and formalisms have beenproposed in the literature and applied to heterogeneoussystems design [14]. They include, but are not limitedto, data flow diagrams, finite state machines, Petri nets,specialized algebras and object oriented techniques.Our position is that the formal specification techniquesare of limited effectiveness without a systematicmodeling methodology guiding their use throughout thecodesign process. With Siemens Personnel, we are

SystemSpecificationModelingModel BaseRefinementSimulation-BasedVerificationExperimentalFrame BaseTechnologyAssignmentHWInterfaceSWFigure 1. Model-Based Codesign

advocating an advanced codesign methodology in whichabstract hardware/software models can be developed andvalidated prior to technology assignment. This approachis illustrated in Figure 1. The benefits of using anabstract system specification as a unifying HW/SWrepresentation are: a) late partitioning, b) stepwiserefinement fostering component reuse regardless oftheir technology, and c) the availability of a referencearchitecture in which components can be specified atmultiple abstraction levels (e.g. system, instruction set,register-transfer, logic, or circuit level in the case ofhardware, and OS, applications, utilities, etc. in the caseof software components.

The above methodology, has been described in detail in[1]. Here, we briefly summarize its major tenets. Ourbasic supposition is that models serve as designblueprints for developing system. The modeling phasedenotes the definition of the system’s components (itsobject model) and associated behaviors. This phaseresults in the system’s model that is subject to avalidation and stepwise refinement process. A validatedmodel is simulated in a specific set of experimental

conditions (called experimental frames) to verify itsadherence to the initial requirements, constraints, anddesign objectives. Technology assignment is thencarried out from the verified model specification.

Our approach lends itself well to the automotiveapplication at hand. The car industry is increasinglyreducing design cycles and is keen saving costs. At thesame time, the electronic components used inautomobiles become highly complex embedded systems.The traditional, separate design of hardware andsoftware and software components is difficult to justify,especially in view of the sophistication of the functionalcharacteristics of the components being built.

In the following section, we define a set ofrequirements for our proposed application of the model-based codesign approach.

3. Requirements for automotive safety

electronic systems

We begin with a set of high level requirements thatautomotive electronics should fulfill. Cost and schedulesare general design and realization process constraints.Reductions in weight and space are required in order toproduce fuel efficient vehicles and to conform to stricterenvironmental pollution laws. The electronics should beminimized in weight and size while providingmaximum safety. It has to withstand extreme operatingconditions of a car, e.g., extreme fluctuations intemperature and relative humidity.

A safety device should be able to detect and suggestsolutions to handle hazardous driving conditions. Itshould interface with standard diagnostic stations whichare used for detailed error analysis. An emphasis mustbe placed on a user friendly interface that could update adriver about the current status of the vehicle and itsenvironment.

Additionally, we perceive requirements that apply to specific subsystems. As indicated before, we arefocusing on a model-based codesign of a unit called autonomous, intelligent cruise control unit (AICC). TheAICC system can be seen as an extension of the regularcruise control, not only keeping a fixed speed, but alsoadapting to the speed of the vehicle ahead. It controlsthe relative speed between two vehicles traveling in thesame lane. Furthermore, it asserts longitudinal elementsof control but no lateral control. Although the system isautonomous, meaning it does not rely on communicationbetween vehicles, the driver remains in full control sincehe or she can override the device, e.g., by braking.

The circuitry of a safety unit must satisfy real-timeconstraints. It should not fail in emergency situations. A

standard cruise control nowadays does not represent atrue real-time design problem. However, the design ofan AICC system must take into account large amountsof data, especially from the vision sensors, and processsuch data in a timely manner so that safety requirementsare met.

In the design of AICC, it is necessary to guarantee thatthe safety distance is kept within a small margin of errorunder normal traffic conditions. In our design, thisrefers to the vehicles in front and back. The deviceshould differentiate between obstacles and movingobjects, warn the driver and suggest or take appropriateactions.

We elaborate on the AICC specifications in Section V.First we provide a general object model that allows us tostructure the domain of automotive safety aspects and toselect a subset of elements that can constitute theautonomous, intelligent cruise controller.

4. Object model definition

Our modeling approach is to first focus on thestructural aspects of a domain in which a particularsystem is being developed. We accomplish this bydefining an object model [18] for the domain, byselecting an instance of this domain model thatunderlies the structure of the system under development,and then by defining behavioral specifications. Thismethodology has been described in detail in [1].

Domain object models are represented using the systementity structures --- a tree like diagrams that reflect ahierarchy of object decompositions and taxonomies[15,17]. A high level view of various aspects ofautomotive safety is shown in Figure 2. (The doublevertical lines reflect a taxonomy of components. Asingle line that denotes a decomposition.)

The SES of Figure 2 was specified with a focus onsafety systems using micro-electronic devices. First, fourbroad approaches were taken to divide the domain ofautomotive safety into a systems aspect, an aspectconsidering collision avoidance, a crash safety aspectand the micro-electronics aspect.

An autonomous intelligent cruise control acts muchlike a regular cruise control. The distinguishing featureis the \"safe distance maintenance\" to the car in front andback, detection of cars in the blindspots and, in thefuture, keeping the car in the appropriate lane. Moresophisticated versions would work with a locationsystem which could be realized using a GlobalPositioning System or an Inertial Navigation System.The first alternative has disadvantages in cities ortunnels, or other places where the reception of radio

Automotive Safety Micro-Electronics Dec Electric Components* Systems Spec Collision Avoidance Crash Safety Dec Dec** Required Self Intelligent Urban Highway Driving Airbag Automatic by Law Supportive Highway Specific Specific Recorder Emergency Call Compatible Airbag Spec Driver Passenger Side BackseatCollision Avoidance Decomp** Backing Road Info ABS Shock Control Autonomous Intelligent Driver Monitor Cruise Control Method Dec AICC Dec Radio Location SituationsFeatures SystemLoc Sys Spec Situation Dec Features Dec In Lane Distance Blindspot Tailgate Obstacle GPS INS Alert AlertElectric Components * HW Comp Dec Com Spec*** SW Comp DecASIC’s Actuators Micro-PCs Sensor Alarm Technology Memory Display Actuator Spec MPC-MD Sensor Spec Tech Spec Modules OS Interface Micro-PC Micron COS Hybrid Modules Dec Throttle BrakesUser Driver Error Maintenance Fail Vision Temperature Pressure Interface Detector Safe Sensor Sensor Sensors & Handler Prssr Sens-MD Vision Spec Pressure SensorAntenna Camera Stereo Infrared Radar Com Spec*** Line-Cam LAN Harness Bus Wiring Organisation Spec Client/Server Centralized DistributedFigure 2. System Entity Structure of the Domainwaves is difficult. For more detailed descriptions ofthese subsystems, we refer the reader to [3,4,6,13].

The selection of an instance from the domain objectmodel is done in our approach using a knowledge-basedtechnique called pruning [17]. In this process, designparameters instantiate the components offered bytaxonomies in the system entity structure tree and ensurethe coupling of elements identified in thedecompositions.

Recall, that our focus is the design of an AICC. Letus assume a safety system with a high budget, highintelligence, medium room and highway as the primaryenvironment. At the Collision Avoidance, we select Autonomous Intelligent Cruise Control from among the

other nodes. For the Hardware aspect ASIC’s,Actuators, a Micro-ProCessor, a Sensor, Technology, aDisplay and Memory are selected. At the Actuator nodeonly the throttle actuator is added since CollisionAvoidance is AICC and the most important reason beingthat the brake is needed to disable the cruise control.From the Sensor node we select the Vision Sensor andRadar. The Technology is Micron for all of the devices.On the Software side for the Micro-PC an OperatingSystem, an interface, and multiple components arechosen. They consist of one driver per sensor andactuator, maintenance as well as a fail-safe, errordetector & handler and user interface modules. Sincethe budget is not constrained at the Communicationsaspect, we select a bus for the inter-devicecommunication. The SES tree shown in Figure 3reflects the hierarchy of AICC’s components.

Through the above object model instantiation process,we assure that some of the requirements are met prior tothe behavioral specification phase. Consider thefollowing design aspects: from a cost standpoint, there

Automotive Safety Systems Spec Collision Avoidance Dec Crash Safety DecIntelligent Highway Road Info ABS Shock Control Autonomous Intelligent Highway Specific Cruise ControlCompatible Method Dec AICC Dec Situations Features Situation Dec Features Dec Distance Tailgate Obstacle Alert AlertMicro-Electronics DecM-E Dec M-E Dec Electrical Components Elec Comp Elec Comp HW Comp Dec Com Spec Bus SW5 SW6ASIC’s Actuators Micro-PCs Sensor Display Technology Memory Modules Actuator Spec MPC-MD Sensor Spec Tech Spec Modules Dec SW4 Throttle Micro-PC VisionMicron Modules User Interface Maintenance SW1 SW2 Vision Spec Modules DecModules Radar Driver Modules Dec SW3 Driver Error Detector & HandlerSW2 SW3 SW5 OS Modules Interface ModulesModules Modules Dec Modules Dec Modules Dec User Maintenance Error Fail DriverError User MaintenanceInterface Detector Safe Detector Interface & HandlerFigure 3. Pruned System Entity Structure for AICC

are no restrictions. Thus any technology can be selected.Room or size are mostly a hardware problem andtherefore constrain the selection of that specific branchin the decision tree. Dealing with real-time needs to beaddressed on the software side. An appropriateoperating system must implemented based on a priorityscheme. Different actions have a different level ofimportance. In case of the AICC updating the sensorreadings should always run at the highest priority. Themodules split the task of monitoring. For example, theerror detection routine detects if sensors are communicating properly.

User friendliness can be accomplished through specialuser interface routines. They could run at a lowerpriority to convert technical data to easilycomprehensible information. In addition, optimizedhardware should be used to support of input and outputdevices. At the right point in time, the display shouldprovide a sufficient amount of information to the driver.He or she should be able to monitor and comprehend avariety of control functions. To properly address this,complexity has to be minimized and functionality mustbe maximized.

Meeting real-time constraints without loosingfunctionality requires that a careful consideration begiven as to which parts of the components are written assoftware routines and which are implemented usingApplication Specific Integrated Circuits. From our pointof view, a model-based design approach tohardware/software codesign is beneficial because we cansolve this problem with early simulation and guarantee arelatively short design cycle. In applying our codesigntechniques, we have to refine each of the softwaremodules and provide a library of ASIC circuits.

5. Behavior specification

In Figure 4, we show a high level block diagram of the

AICC. We now specify the AICC’ s behavioral model.The specifications are derived from the followingassumptions and informal specifications.

The intelligent cruise control is operated using fivebuttons: ON/OFF, RESUME/ACC, COAST,OBSTACLE ALERT and TAILGATE ALERT. Toprevent the misuse

of the cruise control, it cannot be turned on or activatedif the speed of the car is less than 35 mph or if the car iscurrently in reverse or neutral. Tapping the ON/OFFbutton once turns on the cruise control, and doing thattwice turns it off. Once the cruise control is turned off,it enters a disabled state.

When the COAST button is tapped, the cruise controlis enabled and the desired speed is maintained if thedistance to the vehicles in the front is more than orequalradarAICC UnitspeedObstacle ModuleTailgate Modulethrottleengine loadHWInt.SWHWInt.SWindicatorson/offData Handling Moduleresume/accHardwareInterfaceSoftwaredisplaytailgateMain ModuleobstacleHardwareInterfaceSoftwareFigure 4. High Level Block Diagram for the AICCto the required safety distance. If the safe speed is lessthan the desired speed, the desired speed is saved, thecar adjusts the throttle to reach the safety distance andthen attempts to resume the desired speed. Thisaccomplishes the goal of keeping the safety distancefrom vehicles in the front at all times. During theenabled state, power is decreased if the speed exceeds 2mph above the currently requested speed or increased ifit drops 2 mph below that mark. The currently requestedspeed is either the safe or the desired speed. Pressing theCOAST button in the enabled mode results in reducingthe desired speed. This results in deceleration if the caris traveling at the desired speed.

If the TAILGATE ALERT option is activated, the unitchecks if the distance to the car in the rear is more thanor equal to the safe distance. If the safe distanceconstraint is violated, the car flashes both rear indicatorlights which has the intended effect of having thevehicle behind slow down or pass. To maintain safetydistances two radar devices - one in the front and one inthe back - are used.

RESUME/ACC resumes to previously set speed (ifthere is one) when the unit is in the disabled mode.Otherwise, this button increases the desired speed.

An OBSTACLE ALERT option warns a driver if anobject ahead is traveling at less than 50% of the driver'scar's current speed. This warning mechanism is also afunction of the current distance. It is questionable if thisapplication should be used during passing maneuvers ontwo-way roads.

The unit is reset to the disabled state by tapping thebrake, engaging the clutch, or if the speed falls below 35mph. The two options TAILGATE and OBSTACLEALERT remain enabled regardless of the mode the

cruise control is in. A statechart representation of thebehavioral model in shown in Figure 5.

The control unit also obtains data from the internalsensors. The vision sensors are typically chosen to beradar units as shown in Figure 4. The data arrivesaccording to a specified rate given by a specific protocol,e.g., a CAN bus used by a lot by automobilemanufacturers today. From this data, information aboutthe distance and relative speeds of the surroundingAutonomous Intelligent Cruise Controlpower onAICCOffin [ON/OFF] &Speed>35mphin [ON/OFF] / turn off cruiseradarlightmalfunctioning /Initializationdisplay errorDo:AICCWanted_Speed = 0radar fine/OnCheck Radarsturnon cruise lightAutonomous Cruise Control OnIntelligent Cruise ControlOperationData HandlingUpdate DataTailgate Detector Modein[TAILGATE ALERT]Tailgate AlertObstacle Warning Modein[OBSTACLE ALERT ]Obstacle Alert Update DataSafe_Speed < Curr_Speed/Curr_Speed = Safe_SpeedAQUIREDo:TIMER update readings for rear & frontDo: radar(safe_dist_f,safe_dist_r)wait for time intervalSafe_Speed > Curr_Speed & Safe_Speed > Curr_Speed &Safe_Speed >= Wanted_Speed/ Safe_Speed > Curr_Speed &Curr_Speed = Wanted_SpeedSafe_Speed < Wanted_Speed/Curr_Speed = Safe_SpeedOperationSLEEPDO:wait for buttonin [RESUME/ACC &FORWARD & Wanted_Speed>35]/Curr_Speed = Wanted_Speedin [BRAKE | !FORWARD |CLUTCH | Speed=<35]OR in [COAST & FORWARD& Speed>35] /Wanted_Speed = SpeedCurr_Speed = Speed Speed > Curr_Speed + 2 /HOLD SPEED decrease throttleDO:Speed < Curr_Speed - 2 /keep throttle setting increase throttle in [COAST] / Wanted_Speed -- in [RESUME/ACC] / Wanted_Speed++Tailgate AlertAlert IdleTailgate Bit = 1Do [forever]: determine if rear tailgate (withFlash Rear Indicatorssafe_dist_r, rel_speed) and re/settailgate detector bit Tailgate Bit = 0 /Rear Indicators OffObstacle Alertrel_speed_o<.5*speed /turn off obstacle light rel_speed_o<.9*speed /Alert Idlehorn offDo [forever]: determine if object in front (withsafe_dist_f, rel_speed_o) rel_speed_o>.5*speed /turn on obstacle lightrel_speed_o>.9*speed / horn onFlash Rear Indicators REARREARINDICATORS OFFINDICATORS ONDo:Do: wait for time interval wait for time intervalFigure 5. The Equivalent Statechart Representationf (engine load)AICCthrottle settingCarGeneratorAcceptorTransducerYes / NoFigure 6. AICC with Experimental Framevehicles can be obtained. Other information can beretrieved from the speed sensor or sensors measuring themomentum of the car.

6. Experimental conditions

In our methodology, system models are verified usingsimulation. Experimental frames [16,21] are employedto define circumstances under which the model issimulated and observed. An experimental frame consistsof a generator, an acceptor and a transducer. It is ameans of instrumenting a simulation experiment with amechanism that a) subjects the system’s model to thesimulated effects of the environment on the system (thisis handled by a generator), b) collects and monitors theeffects of the system on its environment by observing thesystem’s model’s outputs (managed by a transducer),and c ) controls the simulation experiment through anacceptor module. For a schematic representation, pleaserefer to Figure 6.

Figure 6 illustrates how the design is tested for its basicfunction of maintaining the speed within limitsassuming that not interrupt events are generated (that is, no event that would disengage the AICC occurs). Thecar can be viewed as a environment that has various

characteristics depending on the model. It isrepresented as an experimental frame. This means thatthe output function of the generator corresponds to anengine load per specific model specifications. Theresponse of the AICC unit in form of the throttle settingis then evaluated by the transducer. Finally, to observethe behavior in the different states of the cruise control, e.g., OFF or CRUISE, and to test for correct statetransitions, the acceptor is be used.

The AICC simulation model was developed using anhouse discrete event simulator DEVS-Java [21]. Themodel was decomposed in a manner that corresponds tothe functional decomposition of the real AICC. Adiagram of the model is shown in Figure 7. Afterbuilding and testing the atomic models or componentsthe model was then extended to the final coupled model.It consists of a state manager which keeps track of thestate of the cruise control which is mostly influenced bythe user, the data manager which obtains data from thefunctions and the sensors and distributes it to thecomponents that request it, and finally the functionswhich each solve different calculations.Since this model is being implemented on a singleprocessor environment (Motorola 68HC11EVB) anadditional component, the scheduler, was added to theAICC. This component was necessary to eliminate concurrent execution that can be achieved during thesimulation, but which cannot be realized in a singleprocessor implementation. We thus obtained a validmodel which can be used to resolve timing andfunctionality issues, i.e. to determine the bottlenecks ofthe system.

Along with the model a general user interface (GUI)was developed to test the model of the AICC. It providesan interface which is common to a car. While thesimulation is running the user can manipulate cruisecontrol buttons, speed of the car with the cruise controland a profile of the car ahead with this interface. Thisputs the AICC in a closed-loop environment where theGUI is coupled to the model of an actual car.

7. Conclusions

This paper summarizes our current work to develop atestbed for the model-based codesign methodology. Theautonomous, intelligent cruise control module is beingrealized using the techniques presented above. At thehigh level the system will be tested according to thespecified requirements and then iteratively refined downto the lowest level where the design decisions about theimplementation in hardware or software will be made.

Clearly, the technology assignment phase remains acritical issue. As we have pointed out in [1], technologyassignment is not as limited as a target architecture boundpartitioning scheme used in most existing systems today.This is because the implementation independence of thedesign persists up until this very assignment step. Thecomponents of the validated system model can be bound tomodules of possibly different technology.

The interfaces and their synthesis are again a central pointof technology assignment. In fact, the dual steps ofpartitioning and integration is now replaced by a stepwiserefinement procedure based on an abstract behavioral modeland the interface synthesis step. The problem as such hasnot, however, become easier. Interfaces are generated basedon component interrelations derived from the refinedmodel. Depending on the technology choice,

Experimental FrameoutFunctions forBusspeed, distance, cntrlspeed of aheadgenrprovidesinoutinputs inControlcontrollerScenarios offormatoutbuttons pressed,clutch,brake,gasGeneratorDataAcceptorstarts and endssimulation cycleTransducertransinanalyzes throttleresponse andevaluates messagesmsginstatus in AICC Control Unit BridgeState ManagerCNTRL inext: schedule next intint: change state, i.e.: sleep,inititialize,off, incr,decr,activated, resume,error,setout: notify calc mod or msg to EFactionmsgSM inSM outDM inDM outinreqinreqinreqreqmsgstopreq Throttleext: request data & calc int: passivateout: send value to EF Setext: request data & calc outint: passivateout: notify safety & DM Calculation Module Safetyinext: request data & calc int: passivateout: notify DM & throttle req if needed Incrementext: request data & calc int: passivateout: notify safety & DM Data ManagerDATA inext:handle direct req & incoming dataint: change state, i.e. waiting,pause, error,accessing out: notify fnct or msg Decrementext: request data & calc int: passivateout: notify safety & DM outreqext: request data & calc int: passivateout: notify throttle if needin Adjust SpeedinoutoutthrottlesettingstatusFigure 7. Diagram of the AICC Simulation Modeleither signal exchange, interrupt, or other synchronizationmeans are chosen. In our proposed codesign methodology,alternative designs can be evaluated with respect to variouscriteria, e.g., the allocation (binding) of behavioral modelsor functionality to action modules (HW, SW, interfaces).

This assignment phase is guided by the performanceestimation results obtained in the simulation step.

We are currently developing a model-based representationof the AICC module and its various subcomponents. A setof simulation experiments for virtual prototyping and the

physical realization of the AICC is being used to validateits specifications. We are also designing backtrackingsearch-based algorithms to facilitate the technologyassignment process.

Acknowledgments

This work has been supported by Siemens AG, CentralResearch and Development Laboratories, Munich,Germany.

References

[1] K. Buchenrieder and J.W. Rozenblit. Codesign: An

Overview. In J.W. Rozenblit and K. Buchenrieder (Eds)Codesign: Computer-Aided Software/HardwareEngineering, 1-16, IEEE Press, 1994.

[2] R. Bündgen and W. Küchlin. Term Rewriting for

Hardware and Software Design. In J.W. Rozenblit andK. Buchenrieder (Eds) Codesign: Computer-AidedSoftware/Hardware Engineering, 19-40, IEEE Press,1994.

[3] P. Carrea, A. Saroldi. A Prototype Vehicle for

Integration of Driver Support Functions: The AlertProject. Proceedings of the First World Congress onApplications of Transport Telematics and IntelligentVehicle Highway Systems, Vol.4, 2209-15, Paris, France,December 1994.

[4] K. Ehlers. Das Automobil - eine beispielhafte

Anwendung von Mikroelektronik.. Impulse, No.9,VOLKSWAGEN AG, 5-12, Wolfsburg, Germany,December 1991.

[5] J. Forrest. Implementation Independent Descriptions

Using Object-Oriented Approach.. In J.W. Rozenblit andK. (Eds) Codesign: Computer-Aided Software/HardwareEngineering, IEEE Press, 1994.

[6] F. Gnavi, R. Risser, M. Carrara. Result of the

Application of the PROMETHEUS Traffic SafetyCheck-List for the Safety Evaluation of the AutonomousIntelligent Cruise Control. Proceedings of the FirstWorld Congress on Applications of TransportTelematics and Intelligent Vehicle Highway Systems,Vol.4, 2192-9, Paris, France, December 1994.

[7] R.K. Gupta and G. De Micheli, Hardware-Software

Cosynthesis for Digital Systems, IEEE Design and Testof Computers, 10(3), 29-41, 1993.

[8] R. K. Gupta, N.C. Coelho Jr., and G. De Micheli.

Program Implementation Schemes for Hardware-

Software Systems, IEEE Computer, 27(1), 48-55, 1994.

[9] T.B. Ismail and A.A. Jerraya. Synthesis Steps and

Design Models Codesign. IEEE Computer, 28(2), 44-53,February 1995.

[10] A. Kalavade and E.A. Lee. A Hardware-Software

Codesign Methodology for DSP Applications. IEEEDesign and Test Computers, 10(3), 16-28, 1993.

[11] A. Kern and A. Bazevicius. A Concurrent Hardware and

Software Design Environment. VLSI Systems Design,34-40, August 1994.

[12] S. Kumar, J.H. Aylor, B.W. Johnson, Wm. A. Wulf, and

R. D. Williams. An Abstract Hardware/Software ModelFor Easy Performance Evaluation. Proceedings of the1995 IEEE Symposium and Workshop on Engineering ofComputer Based Systems, 299-306, Tucson, AZ, March1995.

[13] A. Puasteri, A. Streit, J. Gardener. Inertial navigation

and GPS compared for automatic vehicle locatingsystems. ISATA Proceedings, 901-5, Aachen, Germany,1993.

[14] J.W. Rozenblit and K. Buchenrieder. Codesign:

Computer- Software/Hardware Engineering. IEEEPress, 1994.

[15] J.W. Rozenblit and J. Hu. Integrated Knowledge

Representation Management in Simulation BasedDesign Generation, IMACS Journal of Mathematics andComputers in Simulation, 34(3-4), 262-282, 1993.

[16] J.W. Rozenblit, J.W., Experimental Frame Specification

Methodology for Hierarchical Simulation Modeling,International Journal of General Systems, 19(3), 317-336, 1991.

[17] J.W. Rozenblit, J.W. and Y.M. Huang, Rule-Based

Generation of Model Structures in MultifacetedModeling and System Design, ORSA Journal onComputing, 3(4), 330-344, 1991.

[18] J. Rumbaugh. Object-Oriented Modeling and Design.

Prentice Hall, 1991.

[19] J. Staunstrup. Towards a Common Model of Software

and Hardware Components. In J.W. Rozenblit and K.Buchenrieder (Eds) Codesign: Computer-AidedSoftware/Hardware Engineering, 117-127, IEEE Press,1994.

[20] P. A. Subrahmanayam, Hardware-Software Codesign:

Cautious Optimism for the future, IEEE Computer,26(1), 84, 1993.

[21] B.P. Zeigler. Object Oriented Simulation with

Hierarchical Models, Copyright by Author, 1995.