Virtual Component Testing for PEM Fuel Cell

3rd European PEFC Forum, Session B09, Thursday, 7 July, 09:15h, File No. B092

Virtual Component Testing for PEM Fuel Cell Systems: An Efficient, High-Quality and Safe Approach for Suppliers and OEM´s Carl-Johan Sjöstedt and De-Jiu Chen, KTH, Brinellvägen 83, S-10044 Stockholm Peter Prenninger, AVL List GmbH, Hans-List-Pl. 1, A-8020 Graz Ian Faye, Robert Bosch GmbH, Robert-Bosch-Pl. 1, D-70839 Gerlingen Th. Hülshorst, FEV Motorentechnik GmbH, Neuenhofstr. 181, D-52078 Aachen Ashley Kells, Intelligent Energy Ltd, 42 Brook Street, UK-W1K 5DB London Ian Harkness, Johnson Matthey plc, Blount´s Court, UK-RG4 9NH Reading Carsten Schönfelder, VKA RWTH Aachen, Schinkelstr. 8, D-52062 Aachen

Abstract The successful introduction of fuel cell systems for future generation automotive applications will significantly depend on the development and realization of reliable low cost components, which have to be highly integrated in the fuel cell system. Hence, in the course of the project NFCCPP (Numerical Fuel Cell Component Performance Prediction tool) funded by the European Union, a simulation environment has been worked out and a modular component tool box created, which allows the – virtual – testing of components of fuel cell systems in a highly realistic, most advanced and precise, but nevertheless confidential simulation environment. Confidentiality – in fact model protection - enables the combination of best state of the art simulation modules from different partners in an overall system simulation model without having access to confidential information and data of other individual components. Even competitors can test their components together in such an environment. Moreover, this approach enables investigations based on overall system simulations (or a fixed set thereof), which have the advantage of providing a sound reference for comparing results.

Introduction Throughout the last decade numerous candidate fuel cell technologies have been in the focus of generic and pre-competitive research and technology development for a large variety of applications. After the fuel cell’s first appearance in space industry to power satellites and spacecraft, fuel cells were identified additionally as a potential saviour from the ever increasing debate around reduction of green-house gases and thus protection of the earth’s atmosphere. Since one third of the energy consumed in the European Union is used in buildings, investigating the application of fuel cell technology for stationary power generation was a logical consequence. Using fuel cells in the automotive industry for replacing the internal combustion engine as prime mover by a fuel cell system is even more challenging as far as reliability, cost, safety and Europe-wide operability are concerned. Fuel cell systems for automotive applications are complex power systems consisting of different component groups as shown in Table 1.

1

Group Air Management Auxiliaries Control Driveline Model Fuel Processing

Components Compressor/expander, humidifier, filter, mass flow sensor, water separator Pumps, piping, valves, pressure regulator Supervisor, anode, cathode, thermal, power electronics Motor, transmission, vehicle Reformer (partial oxidation, steam, autothermal, ammonia cracker), reformate cleaning (shift reactor, preferential oxidation) Liquid fuel tank, compressed H2, electrolyte storage Fuels, mixtures, thermodynamic equations and data DC/DC converter/inverter, battery PEM, AFC HEX, radiator, start-up burner, off-gas burner, cooling fan

Fuel Storage Material Properties Power Management Stacks Thermal Management Table 1: Component Group Definition

These components interact closely together and influence the entire system behaviour. The general challenges in the development of components for fuel cell systems for different fuel cell applications are: • • • • • • •

Understanding and defining development goals (i.e. component specification) Improvement of system efficiencies Reduction of production costs Improvements of availability and reliability Reduction of weight and required space Optimisation of dynamic behaviour (incl. start/stop strategies and charging system) Further component optimisation (e.g. noise reduction)

This paper begins with a brief discussion of the basic approach taken including the goals of this work. This is followed by a description of simulation module methodology and standardisation of interfaces. A more detailed description of fuel cell modelling and fuel processing to generate hydrogen is presented, followed by a discussion of the overall system model. Finally the topic of model encryption and protection is presented as a means of exchanging confidential simulation models in a common platform. The paper is then concluded with a summary and acknowledgements.

Basic Approach In order to develop and optimise single components it is necessary to understand the interaction between the system and the component under development. Thus a "Numerical Fuel Cell Component Performance Prediction Model" has been developed within the NFCCPP project to fulfil the particular needs of component manufacturers for a fast and effective simulation tool to evaluate component performance within the fuel cell system. This model is going to be used as a "Reference Model" for fuel cell systems. This reference model contains all known components and sub-systems to date which will be modelled with non-confidential information and modelling know-how, featuring • High degree of modularisation for fast and easy access to the components

2

• • •

Standardised I/O signals for the components to enable the use of each simulation blocks at different positions (if physically possible) A graphical user interface to allow a wide range of experts to interact, even if one is not a specialist in the specific software environment Easy changes to the system parameters (e.g. model and control parameters)

The tool enables the user to remove the module of each component within the existing model, and to put a very detailed, self-developed module into the model and generate information about the component behaviour in the complete system. There will be a growing acceptance of the results if component manufacturer and their customers use the same reference model for their performance predictions. It is assumed that especially smaller and medium sized companies will profit from such a standard tool since they presumably have little interest in developing a complete fuel cell system model with their own internal resources, but would profit from the ability to assess the performance of their components in the system. Once the model is established it can be improved by exchanging standard modules with enhanced models provided by component manufacturers on a voluntary basis. It is assumed that model quality is improved by using proprietary company information. Such models would thus be provided only if the protection of this confidential information included in the different component modules can be guaranteed. This includes but is not limited to: • Prohibition of any reverse engineering of the models • Prohibition of getting access to model data such as measurement data • Avoiding direct interrogation of the model in order to quantify model behaviour

Component Manufacturer NFCCPP User

Request for enhanced Model with slot

Development investigations (Component Manufacturer)

Governing Body (regulates usage)

Own product models in freed slot

“SPEC” for specific user model

Neutral compiling services (creates protected model) Standard I/O and Model Parameters

Reference System-Model

Effect on system behaviour

Front-End knows “SPEC”

Non-transparent Model (with more precise models)

Non-transparent Model (with slot for NFCCPP-User model)

Figure 1: Basic process of getting access to a protected model

3

Model protection can be done in different ways with different degrees of protection. In any case a procedure ruling the handling the confidential information is necessary. This could work as follows: A component manufacturer is going to develop a certain component for a fuel cell system. The manufacturer sends a request for a model variation with a slot for its component to a so-called "Governing Body", which regulates the usage of the proprietary information. The Governing Body generates a specification "SPEC" and provides it to a neutral compiling service that automatically creates the protected model (e.g. a dll in Matlab/Simulink that cannot be decompiled). Now the component manufacturer has access to a protected model to be used for component development. The whole process is shown in Figure 1. Obviously, the creation of such an easily accessible simulation environment requires clear and strict definitions of the interfaces of the modules and a basic set of well-elaborated modules as well as an user interface, which are explained in more detail in the subsequent chapters.

Standardization of simulation modules & interfaces In order to facilitate a simulation tool that allows flexibility in terms of the system simulated and the sub-components used, it is clearly of high importance to have a clear definition in terms of individual component boundaries and the connection methodology employed between components. To this end, a hypothetical fuel cell based automotive drive train was defined and broken down according to the categories in Table 1. The definition of these broad ranging components not only aids in the validation of the tool, but also provides an extensive library from which system models can be developed. To enable ease of component connection and interchange, a standard connection methodology was devised. The basic premise of this was to use generic connections in the form of mechanical, electrical and fluid connections (Table 2). Since Simulink is a casual simulation system the inputs and outputs to each component have to be strictly defined, as opposed to other simulation packages which calculate its own cause and effect from given equations (e.g. Flowmaster, Hopsan) (1). A component-based approach was used, i.e. the components were modelled the way component manufacturers were used to model them, and then the system was then assembled out of them. In some cases, this led to small alterations of the components to fit in the system. The mechanical and electrical connections both work the same way: If the Speed/Voltage is selected as an input, Torque/Current is used as an output and vice versa. In all components the most convenient input and output was selected. By using this method, a proper cause and effect action/reaction can be assured for the system and thus give efficient calculations (2). For the fluid connection, the Pressure and Mass flow have about the same functions as Torque/Speed. In addition, the Temperature and Mass fractions are included in this connection to calculate the fluid properties, including density, heat capacity, and more, inside each component. The Temperature and Mass flow information are both assumed to always be in the same direction as the main flow direction. It was decided early in the project that the input mass flow always should be used as an input together with the downstream pressure. Using this method for all the fluid connections, all components will have the same input and output, and can then be connected in any order.

4

In addition to the Mechanical, Electrical and Fluid connections, there are also control signals, for example “requested torque” or “measured mass flow”. They can be used only as input or only as output from the system; in a real system they will probably be electric control signals, (e.g. 0-10V). Mechanical Torque (Nm)/ Speed (rad/s)

Electrical Current (A)/ Voltage (V)

Fluid 1 Temperature (K) Total mass flow (kg/s) Mass fraction , element 1 Mass fraction, element 2, …. Mass fraction, element n Table 2: Generic Component Connections

Fluid 2 Pressure (Pa)

Through use of the connection scheme of Table 2, a component may be defined as shown in Figure 2:

Downstream fluid pressure

Pressure to upstream

Fluid connection in

Fluid connection out

Electrical connection in

Component

Electrical connection out

Mechanical connection in

Mechanical connection out

Control signal in

Control signal out

Figure 2: Component connections It should be noted that all types of connection are possible for each component, and in fact some components may have multiple connections of the same type (for example a fuel cell model may have fluid connections for the anode, cathode and cooling streams along with an electrical connection). By adopting this approach it is possible to easily integrate models into the NFCCPP environment.

Modelling of fuel cells and fuel processing units Much work has been completed previously in the field of fuel cell simulation (3 – 6), with each being most useful for its own specific purpose. The spectrum spans from detailed models developed using computational fluid dynamics (typically computationally expensive) to empirical based models just mapping measurement of existing hardware (more efficient in terms of computation time). Whilst it is theoretically possible for models of any level of detail to be incorporated into the NFCCPP tool, the fuel cell model developed and implemented is largely empirically based with some theoretical calculations. The electrochemical reaction that takes place within a fuel cell can be represented using the following equations; 5

O2use =

I 4⋅ F

1

H 2use =

I 2⋅ F

2

H 2O prod =

I 2⋅ F

3

Where O2use, H2use, H2Oprod are the oxygen use, hydrogen use and water production (moles/s), I is the stack current (A) and F is the Faraday Constant (A/Mol). The polarisation curve characterizes the performance of the cell based on these electrochemical processes and is typically represented either as a look-up table, or in the form of a function fitted to collected data. One such function described according to (4) takes the form:

Ve = VeO − VTafel − VOhmic − VMassTransport Where: Ve VeO VTafel VOhmic VMassTransport

4

Stack voltage (V) Open circuit voltage (V) Represents the kinetic losses in the reaction (V) Represents the ohmic losses due to the electrical resistance of the membrane material (V) Represents the losses associated with transporting the gases to, and removing water from the reaction sites (V)

The above are defined as: VTafel = b ⋅ log(i )

5

VOhmic = i ⋅ R

6

VMassTransport = m ⋅ e ni

7

Where: i

Current density (A/cm2)

b

Empirical constant (V/decade)

R

Empirical constant (W/cm2)

n

Empirical constant (cm2/A)

m

Empirical constant (V)

By selection of the empirical constants, equ. 4 may be used to represent data collected experimentally (Figure 3). 6

65

60

Voltage (V)

55

50 Experimental Trend 45

40

35

30 0

10

20

30

40

50

60

70

Current (A)

Figure 3: Empirical equation fitted to experimental data As with the polarisation curve, the pressure drop of the anode and cathode fluid streams are typically defined using data fitted to a function, and the fuel cell and coolant exit temperatures can be found by performing a power balance on the system: Pheat = Pin − Pelec − Pout − Penv

8

where: Pheat

Heating power (kW)

Pin

Power into system from fluid streams (kW)

Pelec

Electrical stack power (kW)

Pout

Power in exit fluid streams (kW)

Penv

Power lost to the environment (kW)

The simulation of reformers for fuel cell systems is less well developed than the modelling of the fuel cell itself. Models in the literature range from steady state thermodynamic based simulations (7, 8) to dynamic models describing start up and/or turn down behaviour (9 - 11). Whilst detailed kinetic models of reforming reactions on nickelbased catalysts are common in the catalysis literature there is a lack of published information on the more relevant platinum group metal (PGM) based materials. The higher activity of the PGM catalysts results in smaller systems and thus an improved dynamic response. The air tolerance of these materials is also required for start up and shut down. There is a wide variety of ways a gasoline reformer system could be configured, however the modular nature of the NFCCPP software ensures that all of these can be simulated. This is vital as reformer layout is one of the key system design decisions and it is essential that any simulation tool can input into this decision.

7

As a reference system the layout below was chosen, whilst this is a realistic system layout it should not be viewed as definitive.

Figure 4: Layout of reformer subsystem The heat exchanger models are generic blocks with heat exchange rate, heat capacity and internal volume all parameterised independently to allow simulation of any heat exchanger, real or conceptual. This means that the models are reusable and can be used to investigate the feasibility of alternative layouts. All the reactors are coated monoliths rather than packed beds, this is because monoliths give greatly improved thermal dynamics and reduced pressure drop. Detailed kinetic models are not required (or indeed available) therefore the activity of the reactors is simply simulated using a conversion vs. temperature function. The heat balance is then calculated assuming complete thermal equilibrium between the reactor element and the gas. Since it is hoped to use the software tool for “hardware-in-the-loop” control as well as for simulation, it is necessary to exclude algebraic loops from the model. This means that the temperature of the block from the previous time step has to be used to calculate the reaction rate and then the appropriate temperature change added to this temperature for the next time step. Heat loss is calculated by assuming a typical rate of conductive losses to the surroundings. In the autothermal reformer the higher activity of the partial oxidation reaction relative to steam reforming is simulated by first calculating the amount of gasoline converted by partial oxidation. The conversion of any remaining gasoline by steam reforming is only then calculated. This approach gives temperature profiles down the reactor in reasonable agreement with experiments. The relative amount of oxidation and steam reforming is also determined by the oxygen to carbon and steam to carbon ratios of the feed. The product mix from the reforming reactions is then equilibrated via the water gas shift and methanation reactions. The equilibrium mixture is calculated using free energy minimisation (13). This approach normally involves the solution of a set of coupled nonlinear equations, but since it was decided to use MATLAB/Simulink without any additional add-ons for this project there is no non-linear solver available to efficiently carry this out. Minimisation routines are therefore used instead, with the equations rearranged appropriately and penalty functions used to prevent non-physical results (like negative 8

concentrations). Whilst this approach is not particularly fast it does work accurately and reliably. For the water gas shift reactor a conversion vs. temperature function is used to determine the amount of the mixture which is equilibrated. In the water gas shift reactor methanation is not an allowed reaction and thus methane is not included in the mixture that is equilibrated. In the preferential oxidation reactors both conversion and selectivity for CO over H2 are functions of temperature. Reverse water gas shift activity can be included, if appropriate, through the reuse of a water gas shift reactor block with a suitably altered conversion function. The monoliths are simulated as a series of well mixed volumes, 10 such volumes are sufficient to produce realistic temperature profiles and light off behaviour. The size of the monoliths is determined by the model itself in response to a user input system power parameter. This means that the sizing of the reactors is controlled by the author of the reactor model and means that it is always appropriate. A warning is raised if a space velocity too large for the conversion model to be valid is detected in the block. Condensation of water vapour in the heat exchangers is handled by comparing the partial pressure of water vapour with the saturated vapour pressure and removal of any excess as liquid water. The latent heat released by this condensation is then added to the exiting streams. The temperature used to calculate the vapour pressure is the exit temperature at the previous time step. This slightly artificial approach is required, as proper solution of the vapour equilibrium would require an algebraic loop. The water removed is added to the pure water tank to be used for steam in the reformer when required. In the current version of the models the (small) pressure drop through the monoliths is neglected but all the connections are in place so that this additional detail can be added in at a later date. The approach of using models based on fundamental physics rather than maps of tested components means the reformer model is highly flexible. Systems which vary widely in scale and in layout can be accurately simulated reusing the same blocks. The downside of this approach is that the execution of the model is slow. Results from the reference reformer model (Figure 5) have shown that it represents a feasible system design. The Autothermal Reformer monolith temperature and output composition from an example simulation run are shown in Figure 5. This simulates a start up of the system in which a start up burner is used for the first 50 seconds to preheat the reformer then after 50 s a fuel/air mix is admitted to the reactor and over the next 30 s the carbon to air ratio is ramped from 0.5 to its steady state value of 0.4; simultaneously the steam to carbon ratio is ramped from 0 to 2.2. Once the system has stabilised the output is switched to the stack at 150 s.

9

Monolith Temperature

1400

1200

Temperature /K

1000

Element 1 Element 2 Element 4 Element 6 Element 8 Element 10

800

600

400

ATR Start Up

Start Up Burner

200 0

50

100

Output of system switched to stack 150

200

250

300

Time /s

Figure 5: Autothermal Reformer monolith temperature and output composition from example run of reformer subsystem. The temperature profile is in agreement with experiment with the inlet portion being hottest, due to the exothermic partial oxidation reaction, and then subsequent portions of the reactor cooler due to endothermic steam reforming. Heat loss from the reactor causes a much smaller temperature gradient. The change in temperature at 150 s is due to stack being switched into the system. The ATR temperature spikes slightly, whilst the afterburner controller adjusts to the reduced hydrogen flow rate, and then equilibrates at a slightly lower level due to the reduced amount of heat generated in the afterburner. The recovery of heat and water from the afterburner exhaust are found to be sufficient for the system to achieve steady state. This is in agreement with steady state flowsheet analysis of the same system. The output composition shows that this start up protocol gives complete conversion of gasoline and that significant methane is only produced during switch over from the start up burner. The CO:CO2 ratio accurately reflects the affect of the monolith temperature on the water gas shift equilibrium. The dynamic behaviour of the system as a whole is clearly highly complex, due to the number of components and controls involved, in excess of 80 parameters are involved ranging from fuel composition to controller parameters. It has been found that almost all of these have a detectable influence on the dynamic response of the system shows that the level of detail and flexibility included in this model is required to produce an accurate simulation of the dynamics of a real system. It also shows how useful the NFCCPP software is as a system design tool, allowing rapid testing of proposed system layouts.

10

Simulation of complex fuel cell systems Generally, the simulation tool was designed to be modular, flexible and extensible. The simulation environment is based on component libraries to be applicable as a “drag and drop” construction kit. The component models were integrated into the “global fuel cell reference model”, representing a fuel cell hybrid vehicle with fuel cell system with PEM stacks as prime mover for passenger cars, with gasoline reformer, air supply with compressor and expander and offgas use (Table 3). Parameter Value Vehicle mass 1727 Continuous power of electric traction motor 55 Peak power of electric traction motor 75 Voltage of electric traction motor 288 Peak efficiency of traction converter 95 Battery capacity 18.6 Peak power of PEMFC stack 75 No of cells of PEMFC stack 381 Stack efficiency at peak power 45 Maximum stack efficiency @ power 75 Fuel gasoline Peak efficiency of fuel reformer (based in/out 86 LHV, steady state) Table 3: Main data of “global fuel cell reference model”

Unit kg kW el. kW V % Ah KW % % @ kW %

In order to facilitate the process of integration of the components models into the global model, several guidelines and methods first had to be defined and then applied. The different component models and subsystem models of the different partners were tested and documented for the entire operation range with the specified sample times and solver type: A fixed-step solver with sampling times from 0.001 - 0.01 seconds is used to allow a download of the software code to a hardware controller later on. Algebraic loops are prohibited to ensure the numerical stability of the global model. Also expanded algebraic structures are avoided to assure fast initialisation times. Regarding error handling, limitations and saturations are necessarily integrated before each calculation block. Additionally, every signal has defined initial conditions. Figure 6 shows the global model for the simulation of a fuel cell hybrid car, with driver, vehicle and drive, power system (battery), fuel cell and gas and fuel supply. The system controller is placed on the left side, as well as the signal monitoring, analysis and data logging. Additionally, controller models were separated from the hardware models, to enable a fast and universal control layout process, including hardware-in-the-loop tests and rapid control prototyping by downloading the control software directly to the target hardware. Such a method was also used for the expeditious and successful build up of the fuel cell hybrid demonstrator vehicle (14-16). During serial development, however, control functions might be partly decentralized again in view of embedded components controllers. Especially, control engineering is often an underestimated task in the development of fuel cell systems, since many actuators, which are interacting with each other but operating 11

independently from each other, are imperatively necessary to guarantee an optimised and fail-safe system operation (17). The NFCCPP global model can help to find the best operational strategies and control concepts in this field of development. CONTROL orange: control

HARDWARE desired speed [m/s] M_demand [Nm] Fbrake [N] act speed [m/s] @

[drv_prot]

driver Fbrake [N] M_demand [Nm]

act speed [m/s]

DrivingCycle

Motor Current [A] Battery Voltage [V] @

[vhd_prot]

{Power Limits [W]}

vehicle and drive pws_BatCI]

{Power Limits} Battery Control Input

s_BatCMau

Batt_current_Motor_Aux

DC/DC control @

Battery Voltage

Motor Current [epm_prot]

{FCS Con I} FCpowerDem

ms_A300V

FC Voltage Aux Current (300V)

0

Aux Current (12 V)

12V Voltage BatCI BatCMaux

DC/DC Control

Electric Power Management

[U300V] [U12V]

FC Current

@

[pws_BatCI] pws_BatCMau [pws_prot]

pow er system supply voltage V [Coolant out] [Anode out] [Cathode out] p cth in @ 4con

FCpowDem {FCS Con} ams_airinfo

air info

air_req

h2s_h2info]

h2 info

h2_req

hm_tminfo]

tm info

col_req

[fc_4con]

4con

@

[fcl_prot] [fc_4con] [fcs_prot]

[U300V] driver vehicle and drive power system

[fcl_prot]

p cth out

p cth out

coolant in

yellow only analysis

[drv_prot]

[Anode in] [Cathode in]

p cth in

air 2 f c (gas v ector)

air f rom f c

[vhd_prot] [pws_prot]

[Coolant in]

fuel cell

FCSystem Supvervisor

Analysis

current load A

coolant out (f luid v ector) current demand A @300V

supply v oltage V

air inf o @

air request

[ams_A300V [ams_airinfo [ams_prot]

air management system f g f rom f c

fuel cell @

[ams_prot]

air supply system

[h2s_prot] [thm_prot]

h2 supply system thermal management

epm_prot]

Electric Management

[fcs_prot]

FCSystem Supvervisor

results

f g 2 f c (gas v ector) coolant out (f luid v ector)

h2 request

current demand A

coolant in

h2 inf o

supply v oltage V

@

[h2s_h2info] [h2s_prot]

h2 supply system

analyser

return 1 request coolant 1 return 2 request coolant 2 return 3 request coolant 3 return 4 request coolant 4 supply v oltage V

NFCCPP WP5 Global Model with FCS Supervisor vd4 20041216T092339, Schönfelder Institute for Combustion Engines RWTH Aachen University

supply 1 (f luid v ector) supply 2 (f luid v ector) supply 3 (f luid v ector) supply 4 (f luid v ector) current demand A tm inf o @

[thm_tminfo] [thm_prot]

thermal management

Figure 6: Global reference simulation model A graphical user interface (GUI) is used to enable quick and easy access to the system parameters and to allow a wide range of experts to interact, even if one is not a specialist in the specific software environment MATLAB/Simulink®. For this purpose, FEV Studio (18) was chosen as end user GUI for the NFCCPP simulation software. Using the graphical user interface, all editable parameters of the complete system are available for direct access as well as for batch processing. Simulation data can easily be visualised or exported to other data formats. Since the GUI is independent from MATLAB/Simulink®, it needs no additional expert knowledge to use the NFCCPP simulation software. This enables the tool to be used by a wide range of suppliers and OEM´s.

12

Figure 7: Graphical User Interface (FEV Studio), Simulation results Fig. 7 shows an example use of the graphical user interface for parameter variations within the global model. The two windows at the bottom are monitoring the stack power (left hand) and the stack temperature (right hand) of the fuel cell vehicle during an FTP 75 driving cycle. Due to the low power demand at the beginning of the test run and the low stack temperature of the fuel cell stack, which limits the power output of the fuel cell, the fuel cell power is remaining below 20 kW. In this first phase of the driving cycle the vehicle is powered mainly by the electric power of the battery. The simulation results of the stack power and temperature show realistic behaviour for the whole driving cycle, even though the performance of the reference model is not yet verified in all details at the current stage of the project.

Model encryption and protection A key to enabling continuous system evolution as well as building a market for fuel cell components is to allow the exchange of solutions between partners and to facilitate the reuse and integration of models from a third-party. One prerequisite of such an approach is the protection of proprietary component information. A component normally encompasses a variety of information, derived from domain- or technology-specific know-how of a partner, such as algorithms, lookup tables, and parameter setup. Such information represents the intellectual properties (IP), and is considered to be confidential for business and other reasons.

13

A particular challenge in the protection is that some of IP critical component information becomes accessible during system integration and simulation in terms of run-time behaviours, data values, as well as model specifications. It is not enough with simple encapsulation or encryption means. Converting a design model into a binary component (i.e., Simulink dll/mex) has been recommended by MathWorks for IP-protection (19), but does not completely solve the problem. For example, while solution details are encapsulated and hidden in the dll black-box, one can theoretically still clamp a component by recording its inputs and outputs and hence yield its proprietary data and lookup-table. Moreover, there is a possible risk that particular proprietary design information is recoverable from a binary file through reverse-engineering efforts. A complete IP-protection requires both social and technical measures. The social measures are relating to business rules and laws for preventing illegal usages of IP, such as in terms of business contracts, patents, copyrights, and trademarks (20). The technical measures are relating to technologies and tools that provide necessary enforcements of protection, such as cryptography. Although IP-protection plays a key role for componentbased engineering approaches, the maturity of support varies in different domains. For hardware-centered systems, IP-protection and reuse have been established mainly due to the component-based system view and complexity of semiconductor technology (e.g., system-on-a-chip). Many concepts and solutions have been provided; see e.g., (21-24). In automotive industry, reuse is traditionally treated on the basis of physical components, such as ECUs. Current support of protecting simulation models is still rather weak. One possible reason for this is that the need for cross-enterprise reuse of models has not been widely recognized. Although there are efforts in recent years targeting reuse of software and hardware solutions for flexibility and efficiency related reasons, such as AUTOSAR(25) and EAST-EEA (26), the focuses are still on integrations as well as portability related problems. Two basic alternative strategies were considered for enforcing model protection: encryption or access-control. While the encryption strategy is concerned with the form of confidential information, the access-control aims to delimit the amount of information accessible by the third-parties. In combination with possible ways of performing simulation, the following protection variants were identified based on the basic concept proposed in section 2: Variant 1: Centralized Simulation with remote user control. All simulations are performed at a centralized site run by a neutral governing body that collects components from vendors. Protection is achieved by delimiting the accessibility of component models using physical separation in the sense that no component solutions are further distributed to third-parties. Since the governing body constitutes a shared model management and simulation resource, this alternative has many advantages with respect to configuration and variants management, synchronization of collaborative design activities of components in a system, and high-speed simulation. To improve availability of the shared resource and reduce the operating costs, it is preferred that routine simulation tasks are automated such as by offering remote simulation control interfaces. The main limitation of this alternative is that the governing body itself can become a vulnerable point if no encryption measures are adopted. Variant 2: Localized Simulation with Simulation-Time Model Usage Control . This variant supports component exchange between the vendors and users on a bilateral basis. All simulations are performed at the users sites based on encrypted component 14

models supplied by the vendors. The purpose of encryption is to ensure that no IP-critical information is revealed at design-time. The decryption happens at the initialisation-time of simulation, if and only if the current system configuration is valid with respect to the stipulated usages. The success of this alternative mainly depends on the adopted encryption technology and the abilities of detecting unauthorized configurations. One obvious benefit is that the role of “governing body” can now be partially replaced by the component provider whose IP is of concern. This offers flexibility when such a neutral partner cannot be allocated due to organisational and other reasons. Since the entire solutions are distributed to the users, risks due to adapting and bypassing the protection mechanism have to be carefully considered. Variant 3: Parallel Distributed Simulation. This approach partitions an overall system simulation model into parts and provides communication and synchronization services to run the simulations of these parts at different computers in parallel. In this case, protection is achieved by means of physical separation in a similar way as in the alternative 1. One major benefit is that IP critical solutions never leave their vendors sites and hence provides good protection for both providers and users. On the other hand, for complex simulation model, a challenging task is to resolve the necessary data-flow and execution ordering of simulation blocks. Depending on the partitions under consideration, each synchronization problem can be a unique one. A further restriction is that the approach provides a rather weak support for HIL (Hardware-In-the-Loop) simulation due to the non-determinism of the underlying infrastructure (i.e., Internet) with respect to both timing and data. Based on initial proof-of-concept demonstrators built for these alternatives, variant 2 was selected as the most promising one. This solution adopts well-know public-key cryptography and hash functions for model protection (27). As shown in Figure 8, based on a user requested configuration, the supplier provides an encrypted component solution to the user by first converting a simulation block into a dll component, encrypting it with the encryption key, and then generating a hash-value for the stipulated component usage (i.e., a unique “fingerprint” of the configuration). Afterwards, the encrypted model can be integrated in the user’s design. The decryption is performed by a standard usage controller at the user’s site, which is implemented as an S-function (C/C++) within the transferred component, at the initialisation phase of simulation. To prevent clamping, the controller collects information about the user and the current configuration of the overall system simulation model, and produces a hash-value. This value will be compared with the pre-computed hash-value. Any unauthorized change to the original configuration (e.g., adding a scope for recording particular component IO) will result in a totally different value. If these two hash values are the same, a usage will be granted, which in turn triggers the activities of component decryption and enabling. The decryption key is either transferred to the user online after the usage control or embedded inside controller software with the support of secure memory allocation in an offline approach. For the security of information transmission, all communication over the Internet or outside Simulink are also encrypted and signed.

15

User

Supplier

Internet Design-time Config

DLL component Encrypt key

Encrypt Decrypt key

Closed/Cipher component

Run-time (at model init) FPu ,UsrID,...

FPS

Ctrl

1. Acquiring original Config (Is)

Ctrl e.g., only if (FPu ==FPS),

2. Hashing ( FPS=H(Is) ) FP - FingerPrints,i.e., the digest or has h value.

DLL Decrypt

1.Current Config ( Iu ) 2. Hashing ( FPu=H(Iu) )

Figure 8: On-line strategy of model protection by localized simulation with simulation-time model usage control.

Conclusions and summary The simulation environment as developed allows multiple applications: - Based on a simulation model of a reference fuel cell system with state of the art components, a benchmark for the development of individual components and subsystem is available. Thus, this simulation model can act as a virtual test bench for a supplier who can concentrate his research and development on a single component without the need for more know-how about the remaining system. - Simulation models for other fuel cell systems can be generated matching particular applications. Hence, OEM´s can use this simulation environment for communication with their suppliers in order to identify components, which fit best to their system. - Suppliers and engineering providers can co-operate on a high-level basis even during the concept phase without interfering intellectual property. Although bi-lateral exchange of protected models can be exchanged as shown in Sec. 6, the successful implementation of this approach requires the installation of a governing body and a neutral compiling service (as proposed in Figure 1) to easily manage many protected models. Hence, during the last phase of the ongoing project NFCCPP, cooperation models will be elaborated and assessed in view of their practicability and flexibility. Finally, concepts for continuous model updates and validation as well as maintenance of reference models will be investigated in the framework of such future cooperation.

Acknowledgement The results presented in this paper were achieved within the EU-project “NFCCPP” funded by the European Commission under contract number ENK5-CT-2002-00692, which is gratefully acknowledged. The authors would also like to thank especially to the researchers of all other institutions participating in this project – i.e. European Association 16

of Automotive Suppliers, Denso Europe B.V., Liebherr Aerospace Lindenberg GmbH, Magneti Marelli Powertrain, Pierburg GmbH, MIRA Ltd. as well as Forschungsgesellschaft Kraftfahrwesen mbH Aachen - for their most valuable contributions.

References (1) J. Larsson, P. Krus, J-O. Palmberg, Techniques for Simulation of Multi-Domain Systems, Proceedings of The Sixth Scandinavian International Conference on Fluid Power, 1999. (2) V. Kecman, State-Space Models of Lumped and Distributed Systems, pp27-157, Springer-Verlag, Berlin, 1988. (3) J. H. Lee, T. R. Lalk, Modelling Fuel Cell Stack Systems, Journal of Power Sources 73, pp229-241, 1998. (4) S. Shimpalee, W-k. Lee, J. Van Zee, H. Naseri-Neshat, Advances in computational fluid dynamics modeling for PEM fuel cells, Proc. of ASME IECEC, IECEC-2001-10, Savannah, GA., 2001. (5) C. Boccaletti, G. Di Grazia, G. Fabbri, E. Nisticò, Energy models for stand alone power systems, Proceedings of EETI 2004 - 5th International Congress Energy, Environment and Technological Innovation, Rio de Janeiro (Brazil), October 4-7, 2004. (6) B. R. Sivertsen, N. Djilali, CFD modelling of proton exchange membrane fuel cells, Journal of Power Sources 141, pp65-78, 2005. (7) A. Docter, A. Lamm, Gasoline fuel cell systems, Journal of Power Sources 84, pp194200, 1999. (8) J. C. Amphlett, R. F. Mann, B. A. Peppley, P. R. Roberge, A. Rodrigues, J. P. Salvador, Simulation of a 250 kW diesel fuel processor/PEM fuel cell system, Journal of Power Sources 71, pp179-184, 1998. (9) M. Sommer, A. Lamm, A. Docter, D. Agar, Modelling and dynamic simulation of a fuel cell system with an autothermal gasoline reformer, Journal of Power Sources 127, pp313318, 2004. (10) S. Springmann, M. Bohnet, A. Docter, A. Lamm, G. Eigenburger, Cold start simulations of a gasoline based fuel processor for mobile fuel cell applications, Journal of Power Sources 128, pp13-24, 2004. (11) P. Beckhaus, A. Heinzel, J. Mathiak, J. Roes, Dynamics of H2 production by steam reforming, Journal of Power Sources 127, pp294-299, 2004. (12) T. Giroux, S. Hwang, Y. Lin, W. Ruettinger, L. Shore, Monolithic structures as an alternative to particulate catalysts for the reforming of hydrocarbons for hydrogen generation, Applied Catalysis B 56, pp95-110, 2005. (13) R. H. Perry, D. W. Green, Perry’s Chemical Engineers’ Handbook, pp4-33 – 4-34, 1998. (14) S. Pischinger, C. Schönfelder, O. Lang, H. Kindl, Development of Fuel Cell System Air Management Utilizing HIL Tools, SAE Paper 2002-01-0409, SAE 2002 Congress, Detroit /Michigan, 2002. (15) P. Dietrich, F. Büchi, A. Tsukada, M. Bärtschi, R. Kötz, G. G. Scherer, P. Rodatz, O. Garcia, M. Ruge, M. Wollenberg, P.Lück, A. Wiartalla, C. Schönfelder, A. Schneuwly and 17

P. Barrade, “Hy.Power – A Technology Platform Combining a Fuel Cell System and a Supercapacitor Short Time Energy Storage Device”, Proceedings Internationales SATGSymposium,SAE-CH, FISITA; Wil, Schweiz, 2002. (16) S. Pischinger; O. Lang; C. Schönfelder; Th. Steidten, Compressor-Expander Units for Mobile Fuel Cell Systems, MTZ worldwide No.: 2004-07. (17) S. Pischinger, C. Severin, P. Adomeit, J. Ogrzewalla, T. Hülshorst, State Machine-Based Control Strategy for a Gasoline Fueled PEMFC APU System, SAE Technical Papers SP-1827, Fuel Cell Power for Transportation 2004, 2004-01-1475. (18) “FEV-STUDIO” – commercial software product of FEV Motorentechnik GmbH, Germany. (19) Documentation for MathWorks Products, Release 14 with Service Pack 2, MathWorks, (20) K. A. Kaufman, R. M. Tebelak. Intellectual property ABCs: what communicators need to know, IPCC '95 Proceedings of Professional Communication Conference, 'Smooth sailing to the Future'. IEEE International, 27-29 Sept. 1995. (21) S. Hauck, S. Knol, Data security for Web-based CAD, Proceedings of Design Automation Conference, 1998. IEEE. 15-19 June 1998. (22) A. Fin, F. Fummi, A Web-CAD methodology for IP-core analysis and simulation, Proceedings of the 37th conference on Design automation, ACM, June 2000. (23) M. Dalpasso, A. Bogliolo, L. Benini, Hardware/software IP protection, Proceedings of the 37th conference on Design automation, ACM, June 2000. (24) D. D. Gajski, A. C. H. Wu, V. Chaiyakul, S. Mori, T. Nukiyama, P. Bricaud. Essential issues for IP reuse, Proceedings of the ASP-DAC Design Automation Conference 2000. Asia and South Pacific, IEEE. 25-28 Jan. 2000. (25) H. Heinecke, K. P. Schnelle, H. Fennel, J. Bortolazzi, L. Lundh, J. Leflour, J. Maté, K. Nishikawa, T. Scharnhorst, AUTomotive Open System ARchitecture - An Industry-Wide Initiative to Manage the Complexity of Emerging Automotive E/E-Architectures, 2004 Convergence Transportation Electronics Association. (26) T. Thurner, J. Eisenmann, M. Haneberg, S. Voget, R. Geiger, U. Virnich. The EAST-EEA project - a middleware based software architecture for networked electronic control units in vehicles. Electronic Systems for Vehicles, Baden-Baden, Germany, VDI Berichte 1789, September 2003. (27) B. Schneier, Applied Cryptography, Protocols, Algorithms, and Source Code in C, John Wiley&Sons, 1993.

18